Re: Modest proposal, 3 of 3

[bobduff@world.std.com (Robert A Duff)]

In article <575aq0$t4j@netline-fddi.jpl.nasa.gov>,
Van Snyder <vsnyder@math.jpl.nasa.gov> wrote:
>BACKGROUND
>[... same stuff as in proposal 2 of 3]

Did you really need to make us read all that twice?  :-)

>Geschke and Mitchell had a better idea in IEEE TSE SE-1, 2 (June 75) in
>"On the problem of uniform references to data structures":  Design
>languages so that differences in representation are not reflected in
>references.  So the [] vs () for arrays vs functions in C would be
>considered to be a bad idea.

Actually, I think it's a good idea.  The semantics of arrays and
functions are different enough, that I think they deserve a different
syntax.  IMHO, uniform reference is a Good Thing only in cases where the
semantics is closer.  E.g. I think it's a Good Thing that variables and
constants can be referenced using the same syntax (a simple name) in
Ada, because the things you can do with contants are pretty much a
subset of the things you can do with variables -- constants are just
like variables, except they can't change.  In the array-vs-function
case, you can't say "arrays are just like functions except you can't do
do-and-so".  Nor can you say the reverse, "functions are just like...".

Not to mention the fact that overload resolution of "F(X)" is a real
pain for an Ada compiler.  Consider for example:

    type T is array(Integer range <>) of Boolean;
    function F(X: Integer := 22) return T;
    
    if F(33) then -- means F(22)(33)

>Minor incremental changes could bring Ada to the state of allowing one
>to change the representation of objects without changing their
>references.

Minor?  I think there are a *lot* of things that would have to change.
Ada has lots of special-purpose syntaxes for things, which the
programmer can't mimic.  E.g., you can't define an abstract data type
that is "just like" integers, except that it has an infinite range (up
to available memory).  You can define such a data type, but it won't
have literals, range constraints, case statements, etc.

It would be nice if you could define such a data type, but I don't think
it would be "minor incremental changes".

>PROPOSAL for next standardization of Ada
>
>Get rid of ".all".   ...

I think this case is like functions-vs-arrays -- the semantics of things
vs. pointers-to-things is different enough, that I *like* having
explicit syntax for dereferences.  I just wish it weren't so ugly (I
prefer Pascal's "^" to Ada's ".all").  In fact, Ada does allow you to
leave out the ".all" in *most* cases ("X.all := Y.all" is much less
common than "X.Field := Y.Field", which means "X.all.Field :=
Y.all.Field").  I don't think that's such a good thing.

I think "X.all := Y.all" vs. "X := Y" is a perfectly reasonable way to
distinguish pointer-vs-value assignment (except I'd prefer "X^ := Y^"
for the former).  It seems more elegant than having two different
operators for ":=".  Consider integer assignment.  Is that value
assignment?  Well, usually, but if the integers are being used as array
indices in the program, then they behave like pointers.  You don't use a
different ":=" operator to do "A := B" vs. "Table(A) := Table(B)".

By the way, during the Ada 9X design, it was proposed to make ".all"
optional in more cases.  This was before I joined the 9X project, so I
don't remember the details.  I think there was some way to declare, for
a given formal parameter, that ".all" was optional for corresponding
actual parameters.

Your proposal goes much further, if I understand -- you want to make
".all" illegal.

>Removing ".all" breaks source code compatibility with older versions of
>the language, but it's not a disaster.  One could write a not-very-
>difficult source-to-source translator that would replace "a := b" by
>"a => b", whenever "a" and "b" are access types, and then "a.all" by
>"a".  Ideally, this would be an Ada program, distributed in source form,
>without fee.  Maybe even the standard committee could require it
>accompany all compilers.

I doubt if you could write such a translator in less than about 100,000
lines of code.  To do the above transformations, you have to know the
type of every name and expression, which means you have to do overload
resolution, which is a big chunk of code.  OK, maybe 50,000 lines of
code, if you're clever.  Certainly not trivial.  (Unless you happen to
have an Ada front end lying around.)

In addition, you would have to deal with cases like:

    type T is ...;
    type Ptr is access all T;
    procedure P(X: T);
    procedure P(X: Ptr);

    X: Ptr;
    ...

    P(X);

The above is legal in Ada, but would become illegal (ambiguous) under
your proposal.  The above is probably fairly common in real code, too,
for the same reason you mention (sort of) -- somebody wants to write
"P(arg)" and not have to care whether arg is a T or a pointer-to-T.

Don't say that the implicit ".all" is inserted only if needed, thus
making the above legal and calling the second P.  Besides being
confusing and error-prone, such a rule would introduce Beaujolais
effects.

>There's more that could be done to make programs more mutable, less
>fragile, and more efficient, all at once.  See "Not so modest proposal,
>1 of 1" to be posted soon.

I'm looking forward to it.  This is a lot more fun than debating who has
the best picture notation!

- Bob