CVS difference for acs/ac-00081.txt

Differences between 1.1 and version 1.2
Log of other versions for file acs/ac-00081.txt

--- acs/ac-00081.txt	2003/09/30 02:01:10	1.1
+++ acs/ac-00081.txt	2003/10/29 22:54:07	1.2
@@ -291,3 +291,339 @@
 for the special "(null record)" syntax as well.
 
 ****************************************************************
+
+From: Gautier de Montmollin
+Sent: Tuesday, September 30, 2003  5:07 AM
+
+# AI-287 gives us <> to mean the default value of a component. So
+#      (1..0 => <>)
+# is a null array. It's a minor pain to look up the index subtype (but I
+# usually just use 1..0 and see if the compiler chokes), but it's not that big
+# of a deal.
+
+But it is still a tricky workaround for a missing expression (with the
+exception of the String type). Try to imagine you just discover Ada now...
+
+# The alternative is writing a number of pages of RM rules to make these
+# useful (and then having people confused by the rules, whatever they are).
+# Hard to say if it is worth it.
+
+If the (null array) corresponds, say, to an array expression with one
+dimension having a null range, then it *should not* take pages. On the other
+hand, if it you have to write pages, it means that the null array, including
+in the present workaround form(s), is an undocumented feature of Ada95 which
+should be defined in the next standard! In both cases it is worth...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, September 30, 2003  5:48 PM
+
+Gautier de Montmollin said:
+
+> But it is still a tricky workaround for a missing expression (with the
+> exception of the String type). Try to imagine you just discover Ada now...
+
+The standard way to write array literals is tricky???
+
+> # The alternative is writing a number of pages of RM rules to make these
+> # useful (and then having people confused by the rules, whatever they are).
+> # Hard to say if it is worth it.
+>
+> If the (null array) corresponds, say, to an array expression with one
+> dimension having a null range, then it *should not* take pages.
+
+Please go back and read Adam's message; he explains why the rules used for
+string literals or array aggregates won't work for (null array).
+
+> On the other hand, if it you have to write pages, it means that the null
+> array, including in the present workaround form(s), is an undocumented
+> feature of Ada95 which should be defined in the next standard! In both cases
+> it is worth...
+
+The existing rules are fine for the existing forms; there's no problem with
+the RM. (null array) is quite different.
+
+****************************************************************
+
+From: Gautier de Montmollin
+Sent: Tuesday, September 30, 2003  9:10 PM
+
+# > But it is still a tricky workaround for a missing expression (with the
+# > exception of the String type). Try to imagine you just discover Ada now...
+
+# The standard way to write array literals is tricky???
+
+The standard way to write *empty* array literals *is* tricky.
+I did search in vain in the RM a mention of it (how do they compare ?
+do they have an address ?) or at least an example. Is it documented
+somewhere ?
+
+[...]
+# Please go back and read Adam's message; he explains why the rules used
+# for string literals or array aggregates won't work for (null array).
+
+You are right. I just waked up dreaming of Matrix'((null array)) and things
+like (others=>(null array)), (null array). Yes, it will take lines. But yes,
+it is worth the effort. Ada should have a proper expression for an empty set
+(mathematically speaking)!
+
+****************************************************************
+
+From: Nick Roberts
+Sent: Tuesday, September 30, 2003 10:37 PM
+
+If we introduce (null array) and define it as strictly equivalent to (A..B
+=> <>) where A is S'First and S is the expected subtype and B is S'Pred(A),
+that shouldn't be too difficult to define. It would not be permitted for
+multidimensional arrays. RM95 4.2 (10) could be very slightly simplified to
+define a null string literal as equivalent to (null array).
+
+It would have the consequence that if A turns out to be the first value of
+the underlying type (so it has no predecessor), the construct is illegal
+(and raises Constraint_Error). I think this would be just right; in such
+cases you must supply the bounds explicitly. You must supply the bounds for
+multidimensional arrays.
+
+For example:
+
+   type Day is (Mon, Tue, Wed, ..., Sun); -- RM95 3.5.1 (14)
+   subtype Weekday is Day range Mon..Fri; -- ibid (16)
+   subtype Weekend is Day range Sat..Sun;
+
+   type Basic_Pay is array (Day range <>) of Money;
+   type Piece_Pay is array (Weekday range <>) of Money;
+   type Overtime_Pay is array (Weekend range <>) of Money;
+
+   No_Basic: Basic_Pay := (Tue..Mon => <>); -- (null array) would be illegal
+   No_Piece: Piece_Pay := (Tue..Mon => <>); -- (null array) would be illegal
+   No_Overtime: Overtime_Pay := (null array); -- legal (bounds Sat..Fri)
+   No_Name: String := (null array); -- exactly the same as ""
+
+It would be syntactic sugar, but we could say that Ada has a sweet tooth.
+
+I think it's interesting to note that it would be pointless to declare any
+of the above four variables constant; no assignment to any of them is
+possible. If we did, the 'constant' would, in a way, be syntactic sugar.
+It's hard to avoid.
+
+Also, if we were to declare:
+
+   type Day is (Mon, Tue, Wed, ..., Sun, 'X');
+   ...
+
+then we could legally write:
+
+   No_Overtime: Overtime_Pay := "";
+
+in Ada 95, showing, I think, how syntactic sugar can always be misused.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Wednesday, October 1, 2003  6:28 AM
+
+Nick proposed:
+
+> If we introduce (null array) and define it as strictly equivalent to (A..B
+> => <>) where A is S'First and S is the expected subtype and B is S'Pred(A),
+> that shouldn't be too difficult to define.
+
+If S is a modular type, this would not have the effect that you intend,
+I think, unless you and I have very different notions of what a null
+array is.
+
+More seriously, a construct that would raise Constraint_Error more often
+than not, and would do so not to indicate the run-time violation of some
+invariant, but because of definitional problems, would be actively
+harmful in my opinion.
+
+I see this thread as unimportant, and I'd rather let that sleeping dog
+lie.  But if we were to ever pursue this proposal, we should properly
+solve the issues related to multidimensional aggregates and to index
+bounds.
+
+****************************************************************
+
+From: Nick Roberts
+Sent: Wednesday, October 1, 2003  9:10 AM
+
+> If S is a modular type, this would not have the effect that
+> you intend, I think, unless you and I have very different
+> notions of what a null array is.
+
+Ahem, yes. Well, it goes to show that the most difficult thing about
+defining things is not making mistakes.
+
+> More seriously, a construct that would raise Constraint_Error
+> more often than not, and would do so not to indicate the run-
+> time violation of some invariant, but because of definitional
+> problems, would be actively harmful in my opinion.
+
+I contend that the conditions that would cause C_E to be raised would be
+unusual in practice. I think you'll find, in working code, that most
+unconstrained array types (which have 'range <>' for the indices) have index
+subtypes of or based on Standard.Positive. I think multidimensional arrays
+could be reasonably easily accommodated, but this would add a little more
+definition work.
+
+> I see this thread as unimportant, and I'd rather let that
+> sleeping dog lie.
+
+Woof!
+
+> But if we were to ever pursue this proposal, we should
+> properly solve the issues related to multidimensional
+> aggregates and to index bounds.
+
+Pascal, you seem to rebuff the more elaborate suggestions by saying they
+involve too much work, and then rebuff the simpler suggestion by saying it's
+insufficiently elaborate. If you think that there is a need for a new
+construct that provides null arrays for all kinds of array, how can you then
+argue that there is no need for a new construct that provides null arrays
+for some kinds of array? It doesn't make sense.
+
+****************************************************************
+
+From: Adam Beneschan
+Sent: Wednesday, October 1, 2003 11:04 AM
+
+> I contend that the conditions that would cause C_E to be raised would be
+> unusual in practice. I think you'll find, in working code, that most
+> unconstrained array types (which have 'range <>' for the indices) have index
+> subtypes of or based on Standard.Positive. I think multidimensional arrays
+> could be reasonably easily accommodated, but this would add a little more
+> definition work.
+
+In one medium-sized Ada program I wrote, I found that when it declared
+178 unconstrained array types, 158 used Natural or Positive as the
+index type (I use Natural much more often than Positive), and 20 used
+something else.  A few of these 20 were enumeration types, and some
+were other integer types for which I didn't bother to declare a
+"positive" subtype or the like.
+
+But I agree with Pascal that if this syntactic sugar were to be added,
+it would be best to make it work for all cases (in fact, I think it
+would be "best" if the null string literal were legal for string types
+where the index subtype is a modular type [AI-138], since not having
+it work seems to be a rather surprising result).  Even though most of
+the array types I defined in my program wouldn't cause a problem, it
+would still be annoying to have things not work in the other 20 cases
+where they would, and to have to define fake subtypes of enumeration
+types just to make this work so that the compiler would get the bounds
+of a (null array) right in a case where I couldn't care less what the
+bounds are.  The fact is, in most cases where I use a positional array
+aggregate in a statement (i.e. not in an initializer), I really don't
+care what bounds the compiler gives the array; the routine it's being
+passed to is just going to use Arr'First and Arr'Last anyway.  The
+same would apply to a null array, and I wouldn't appreciate having the
+language force me to care about something irrelevant.
+
+Anyway, that's just my feeling as an Ada programmer.  I realize there
+are costs involved in making things work the "best" way.
+
+****************************************************************
+
+From: Jeffrey Carter
+Sent: Wednesday, October 1, 2003  1:28 PM
+
+Adam Beneschan wrote:
+
+Consider
+
+type Index is (One);
+
+type Str is array (Index range <>) of Character;
+type Num is array (Index range <>) of Integer;
+
+Are we supposed to be able to write
+
+Null_Str : constant Str := "";
+
+?
+
+Other messages in this thread seem to imply that this is legal. I ask
+because GNAT 3.15p rejects this:
+
+test_str.adb:7:31: null string literal not allowed for type "Str"
+defined at line 4
+test_str.adb:7:31: static expression raises "Constraint_Error"
+
+so I'm wondering if this is an error in GNAT or a misunderstanding of
+the ARM.
+
+****************************************************************
+
+From: Adam Beneschan
+Sent: Wednesday, October 1, 2003  1:53 PM
+
+No; and under the current rules this would be illegal even if Index
+had more than one value, e.g.:
+
+  type Index is (One, Two, Five);
+
+So GNAT is correct.  Furthermore, unless I missed something, I don't
+think anyone has implied that this is legal.
+
+What I've said is that perhaps the rules should be changed to make
+this legal (big emphasis on "perhaps").  However, even with the change
+to 4.3.3(26) I mentioned as a possibility, this could *not* make your
+above example legal, in which Index is an enumeration with just one
+element.  Since there is only one possible value for Index, there is
+no way that an array of type Str or Num can have a 'Length other than
+one.
+
+Hope this clarifies things,
+
+****************************************************************
+
+From: Jeffrey Carter
+Sent: Wednesday, October 1, 2003  2:39 PM
+
+> No; and under the current rules this would be illegal even if Index
+> had more than one value, e.g.:
+>
+>   type Index is (One, Two, Five);
+
+Three, Sir!
+
+>
+> So GNAT is correct.  Furthermore, unless I missed something, I don't
+> think anyone has implied that this is legal.
+
+Nick Roberts wrote
+
+> Also, if we were to declare:
+>
+>    type Day is (Mon, Tue, Wed, ..., Sun, 'X');
+>    ...
+>
+> then we could legally write:
+>
+>    No_Overtime: Overtime_Pay := "";
+>
+> in Ada 95, showing, I think, how syntactic sugar can always be misused.
+
+But I see now that Overtime_Pay is indexed by a subtype of Day excluding
+Mon, so this is a different case.
+
+> What I've said is that perhaps the rules should be changed to make
+> this legal (big emphasis on "perhaps").  However, even with the change
+> to 4.3.3(26) I mentioned as a possibility, this could *not* make your
+> above example legal, in which Index is an enumeration with just one
+> element.  Since there is only one possible value for Index, there is
+> no way that an array of type Str or Num can have a 'Length other than
+> one.
+
+It seems to me that "range <>" should alway include a null range. The
+problem is not the concept, but that the language has no way to express
+that null range. It would be nice to be able to write a zero-length
+value for any unconstrained array type. The question is if it's worth
+the effort.
+
+> Hope this clarifies things,
+
+Yes, thanks. I was working from memory, and misremembered.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent