From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,8f8cea8602e61aba
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: The Red Language
Date: 1997/09/22
Message-ID: <EGxFIA.43J@world.std.com>#1/1
X-Deja-AN: 274596059
References: <340E2DC5.25D7@worldnet.att.net> <dewar.874578577@merv>
 <EGpw57.8BI@world.std.com> <dewar.874757740@merv>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-09-22T00:00:00+00:00
List-Id: <comp.lang.ada>


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