CVS difference for ai12s/ai12-0020-1.txt

Differences between 1.3 and version 1.4
Log of other versions for file ai12s/ai12-0020-1.txt

--- ai12s/ai12-0020-1.txt	2018/01/27 04:54:50	1.3
+++ ai12s/ai12-0020-1.txt	2018/02/22 07:06:14	1.4
@@ -904,5 +904,62 @@
 Aside: should the image of a null access value be "null" or "[00000000]" (if
 hex) or "[ 0]" (if 'Image)??
 
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Saturday, January 27, 2018  1:28 AM
+
+> The only issue with that is that we don't have a hex image routine 
+> anywhere. Integer_Address'Image is well-defined.
+
+If the (hex) image uses based notation, it can be fed back to 'Value
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, January 27, 2018  11:29 AM
+
+> ...
+> Discriminated task types should display the discriminant values somehow.
+> Perhaps extension-aggregate-ish syntax? Something like
+> 
+>   (task <task id image> with D1 => This, D2 => that)
+> 
+> and then, for consistency, undiscriminated image is
+> 
+>   (task <task id image>) .
+> 
+> Or perhaps we drop the word "task", but then the parens look odd in 
+> the undiscriminated task case. Do we drop them?
+
+I like the word "task" being there, and always using parentheses for composite
+types.
+
+> Nothing special for protected records. 
+
+I would think you would have "(protected <id-of-some sort> with disc1 => X,
+disc2 => Y, comp1 => Z, ...)" to be consistent with tasks, and to make it
+clear that this is not your normal record.
+
+> Presumably Some_Protected_Object'Image behaves like a call to a 
+> protected function with respect to locking.
+> 
+>>   Named-notation syntax is probably the way to go...
+>>   If we do that, then we'd need consistent syntax
+>>   for the null array case (single- and multi-dimensional).
+> 
+> If we define syntax for null array aggregates, then we should use 
+> whatever is agreed upon. Otherwise, how about
+> 
+>    "(1 .. 0 => <>)"
+> 
+>    "(1 .. 3 => (1 .. 0 => <>))"
+> 
+>    "(1 .. 0 => (1 .. 3 => <>))"
+> ? Or perhaps "()" instead of "<>".
+
+"<>" seems better than "()" given the general Ada allergy to empty parentheses.
+
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent