comp.lang.ada
 help / color / mirror / Atom feed
From: slinky.cs.nyu.edu!slinky.cs.nyu.edu!nobody@nyu.edu  (Robert Dewar)
Subject: Re: Unconstrained arrays
Date: 12 Aug 93 15:00:19 GMT	[thread overview]
Message-ID: <24dlu3$5qq@schonberg.cs.nyu.edu> (raw)

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 :-)

             reply	other threads:[~1993-08-12 15:00 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-08-12 15:00 Robert Dewar [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-03-17  0:59 Unconstrained Arrays belteshazzar
2009-03-17  1:49 ` Jeffrey R. Carter
2009-03-17  2:58   ` belteshazzar
2009-03-17  4:15     ` Jeffrey Creem
2009-03-17  5:20     ` Jeffrey R. Carter
2009-03-17 17:56       ` Jeffrey R. Carter
2009-03-17 23:10         ` belteshazzar
2009-03-18 18:31           ` Jeffrey R. Carter
2009-03-20  1:53           ` Peter C. Chapin
2009-03-20  6:45             ` sjw
2009-03-20  9:46               ` Jacob Sparre Andersen
2009-03-20 11:40               ` Jean-Pierre Rosen
2009-03-25 21:11                 ` sjw
2009-03-25 22:30                   ` Robert A Duff
2009-03-25 23:28                     ` Randy Brukardt
2009-03-26  0:03                       ` Jeffrey R. Carter
2009-03-26  1:00                         ` Robert A Duff
2009-03-20 12:15               ` christoph.grein
2009-03-20 15:45               ` Adam Beneschan
2009-03-23  8:26                 ` belteshazzar
2009-03-25 21:21                 ` sjw
2009-03-25 22:03                   ` Adam Beneschan
2009-03-26  1:32                     ` tmoran
2009-03-27  8:39                   ` Jean-Pierre Rosen
2009-03-27 20:07                     ` sjw
2009-03-29 16:24                     ` sjw
2009-03-27 11:57                   ` Gautier
2009-03-17 15:33     ` Adam Beneschan
2009-03-17 23:00       ` belteshazzar
2009-03-17 20:14 ` anon
2001-12-11 17:17 Unconstrained arrays Michael Unverzagt
2001-12-11 18:22 ` Stephen Leake
2001-12-11 18:24 ` Mark Lundquist
1993-08-15  5:01 Alex Blakemore
1993-08-13 21:08 J. Craig Heberle
1993-08-13 12:34 Paul Durbin
1993-08-12 21:23 Robert Dewar
1993-08-12 19:25 Wes Groleau x1240 C73-8
1993-08-12 17:27 agate!howland.reston.ans.net!math.ohio-state.edu!magnus.acs.ohio-state.ed
1993-08-12 16:26 Mark A Biggar
1993-08-12 16:00 Dave Collar d x7468
1993-08-12 15:28 Robert I. Eachus
1993-08-12 13:03 Raymond Blaak
1993-08-12 12:14 cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!howland.
1993-08-12 12:03 cis.ohio-state.edu!pacific.mps.ohio-state.edu!math.ohio-state.edu!magnus.
1993-08-11 23:42 Kenneth Anderson
1993-08-11 23:40 cis.ohio-state.edu!math.ohio-state.edu!cs.utexas.edu!swrinde!menudo.uh.ed
1993-08-11 22:29 Kenneth Anderson
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox