Re: The Red Language

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

In article <dewar.874757740@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Bob Duff said (I'm really really sure it was him :-)

:-) :-) 

Now, how can I prove it?  Hmm.  How about, "We compared maple syrups at
the Vt ARG meeting."  Convinced?

>The concern is for simplicity from a users point of view. We have had this
>long discussion in the (rather tedious) Eiffel-vs-Ada thread about the
>desirability of linear elaboration, and this issue is related. If you have
>a really complex expression and you want to figure out what is being calld
>where, then clearly the one-pass scheme is easier for a human to figure out.

Ah, that makes sense.

I have often thought that the rules ought to allow bottom-up
information, but only left-to-right.  For example, the first argument of
a procedure can be used to resolve the second one, but not the other way
around.  It's always seemed strange to me that the right-hand side of an
assignment statement can help resolve the left-hand side.

So, "X := X + 1;" would be legal, but "X := 1 + X;" would be ambiguous.
(Of course, "X := 2*X;" would also be illegal, which would be somewhat
unfortunate.)

>The question is whether this simplicitly is gained at the expense of loss
>of expressive power.
>
>There is no question that there are cases where the Ada scheme is
>a great advantage:
>
>  generic
>    type Element_Type is private
>  package Set_Package is
>    functoin Empty_Set return Element_Type;
>    function Value (A : String) return Element_Type;
>    ...
>
>It is really useful to be able to instantiation Set_Package for various
>different types, apply a use clause to the insantiations, and have the
>compiler figure out which Empty_Set and Value functions you want.

Yes, that's nice.

>The time that the two-pass scheme begins to cause trouble is in mixed
>operations. For example, one might think it was useful to have all the
>following in Unbounded_String:
>
>(where UString is short for Unbounded_String)
>
>function "&" (A : String;  B : String) return Unbounded_String;
>function "&" (A : UString; B : String) return Unbounded_String;
>function "&" (A : String;  B : UString) return Unbounded_String;
>function "&" (A : UString; B : UString) return Unbounded_String;
>
>But it is a mistake, because now
>
>   Ustring := "abcc" & Stringvar & Ustring;
>
>is annoyingly ambiguous. It is quite easy to trip up on this problem if
>you are not careful in designing such sets of mixed operations.

But this would be illegal in the Red/C++/Algol-68 rules, too.

- Bob