CVS difference for acs/ac-00016.txt

Differences between 1.3 and version 1.4
Log of other versions for file acs/ac-00016.txt

--- acs/ac-00016.txt	2001/11/15 02:34:08	1.3
+++ acs/ac-00016.txt	2001/12/22 04:11:54	1.4
@@ -1,6 +1,6 @@
 !standard  6.3.2(3)                                   01-10-16  AC95-00016/01
-!class uninteresting 01-10-16
-!status received 01-10-10
+!class amendment 01-10-16
+!status received no action 01-10-10
 !subject pragma Read_Only
@@ -308,5 +308,143 @@
 So why do we need a complex (to implement and describe in RM language) new
 feature here???
+From: Craig Carey
+Sent: Thursday, October 25, 2001 12:51 PM
+At 01.10.19 08:20 +0200 Friday, Pascal Leroy wrote:
+ >> I suppose one simple language change would be to allow a deferred
+ >> "constant" to be completed with a variable declaration.
+ >
+ >I believe that you can do that by completing the deferred constant by a
+ >pragma Import, and exporting the variable with a pragma Export, both pragmas
+ >having convention Ada.  Of course, this is assuming that your compiler
+ >supports these pragmas, but then convention Ada is not too hard to support.
+ >
+ >Pascal
+ >
+I tried that and it seems to be a solution.
+[No syntax error can appear [in GNAT] when the text in the External_Name is
+wrong (but that was with the imported local variable being not used).
+So some of the checking could be done after the compile.]
+There is also this associated topic of read-only record fields!.
+I guess that neither feature:
+   read-only spec vars, read-only non-discrete record fields;
+may arrive in Ada 0y unless the two appear together.
+I found out that Ada 95 has already implemented read-only record fields,
+in its own way. Research into the usage of Ada quite possibly might show
+that the current syntax is not designed quite right.
+Here is an example showing how to have a read-only access type.
+package P is
+    type TP is access all TR;
+    Null_TP : aliased constant TP := new TR'(...);
+    type T (Ptr : TP := Null_TP) is limited null record;
+    procedure G (L : in out T);
+end P;
+package body P is
+    procedure G (L : in out T) is
+       X : TP;
+       for X'Address use L.Ptr'Address;
+    begin
+       X := new TR'(...);
+    end G;
+end P;
+--  The use of 'limited' makes T be passed by reference (RM 6.2)
+--   whenever it is passed as a parameter.
+The syntax above looks like it is one that users do not know about or
+that former C programmers might want to avoid even if they do know
+about it (unless they like using 'Address). I had to get information
+by e-mail before I found out that Ada 95 already implements read-only
+record fields.
+The last Rationale on "the needs of users" said this:
+ >Wherever possible, enhanced functionality in Ada 95 has been achieved by
+ >seeking and eliminating such unnecessary assumptions, thereby permitting
+ >the generalization of features already in Ada, and the removal of special
+ >cases and restrictions.
+Someone with similar views, might be noting that:
+    Ada 95 implements a constant or read-only record field feature, but
+    only for fields that are an access type or a discrete type.
+RM 3.7 says:
+ >A discriminant of an object is a component of the object, and is either
+ >of a discrete type or an access type.
+What about making removing the read-only feature from discriminants?.
+Variants could be auto-resized as needed. While it could be opposed, it
+could improve consistency inside the topic.
+At 01.10.21 10:51 +0200 Sunday, Pascal Leroy wrote:
+ >> If it is not immediately obvious why certification
+ >> authorities have heartburn with inlining, let me know and I will explain
+ >> the rationale.
+ >
+ >But then I fail to see why the same certification authorities would not have
+ >the same heartburn with pragma Read_Only.  If the problem with inlining is
+ >that you don't trust the optimizers to do the right thing, then surely
+ >pragma Read_Only would be much worse.  In essence we would have an object
+ >which is constant when seen from certain places and variable when seen from
+ >other places.  Now constancy is a fundamental property for optimizers, as
+ >they use it to avoid reevaluating certain expressions.  If constancy can
+ >vary from place to place, I am ready to bet that optimizers would
+ >occasionally get confused
+A read-only field or spec variable ought be seen as being not 'constant' if
+this is feature occurs:
+    procedures in the defining package can freely alter that package's
+    read-only fields and exported read-only variables.
+Currently seems improvable: to make a record field be read-only, this
+sort technique can be used:
+    package Code_Quality_Stats is
+       ...
+       type EC_Ptr is access constant EC_Rec;
+       type Safe (
+             ...
+             Error_Counters : EC_Ptr;    --  lots of fields
+             ...
+          ) is limited null record;
+       ...
+    end Code_Quality_Stats is
+The keyword 'aliased' is not allowed for discriminant declarations.
+Can Ada be made so that users get a guarantee that the memory holding
+the value of the discriminant will always be able to be written too, no
+matter what the machine ?.
+The rationale listed interfacing (with C, etc.) as a 1st aim (that was
+in "I.3 The main user needs", Intermetrics, Jan 1995).
+The use of 'private' interferes with interfacing and the finer control
+of allowing specifying of a read-only property can advance a need seen
+by Intermetrics years ago.
+If record fields can be read-only then why not just make the package
+spec variables also be able to be read-only ?. It is an indirect way
+to solving that issue.

Questions? Ask the ACAA Technical Agent