From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 12 Aug 93 15:00:19 GMT
From: slinky.cs.nyu.edu!slinky.cs.nyu.edu!nobody@nyu.edu  (Robert Dewar)
Subject: Re: Unconstrained arrays
Message-ID: <24dlu3$5qq@schonberg.cs.nyu.edu>
List-Id: <comp.lang.ada>

Wayne did not put it quite right. It is not that the compiler "cannot figure
it out", since of course in many cases (and in this case in particular) it
certainly could figure out what you meant IF it was legal Ada, but it is not
legal Ada. As is clear in the RM, Ada deliberately outlaws these one element
aggregates, partly because they seem confusing at a programmer level, and
partly because there are (more obscure) situations in which allowing the
resulting additional overloading cases would be tricky. Consider for example:

	"abc" & ('d')

Is the right operand a one element string, resulting in the use of the 
string&string concatenation, or is it a character with redundant parentheses
resulting in the use of the string&character concatenation.

Of course the result would be the same, but you can't have this kind of
semantic ambiguity hanging around (suppose both versions of concatenation
had been redefined to do something completely different from the standard
version, and different from one another).

So often in language design you run across a simple case which you think
should be easy to handle, but then more complex cases come and bite you.
You can take the approach of distinguishing between the cases but this
definitely adds complexity (have a look for example at Algol-68, which
resolved such ambiguities by distinguishing the "strength" of a position,
[roughly the extent to which the required type is known a priori]. There
were several different strengths (including weak, firm and strong), and
the rules of what expressions were valid depended on the strength.

In particular, the rowing coercion in Algol-68, which converts a single
element to a one dimensional array with one element (just what we are talking
about here), applies in a strong position (the original example given would
correspond to a strong position, where you know what type you wanted), but
not in a firm position (the operands of a binary operator are firm positions).

Very nice, problem solved! But many folks found these coercion rules in
Algol-68 tricky, so in practice the Ada approach: "since we can't have it
everywhere, let's not allow it anywhere" seems the right one in this particular
case, although you can't generalize this phiolosophy always, sometimes you
prefer a special exception (e.g. the one in Ada that allows you to omit
the type of array bounds if it is INTEGER, on the other hand, I know people
who DON'T like that particular special case).

  "A designer's lot is not a happy one" 

      (adapted from W.S. Gilbert: Norman, care to fill in the rest of the
      (adapted from W.S. Gilbert: Norman, care to fill in the rest of the

	words for this :-)