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: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: The Red Language
Date: 1997/09/20
Message-ID: <dewar.874757740@merv>#1/1
X-Deja-AN: 274106849
References: <340E2DC5.25D7@worldnet.att.net> <EGIJ8B.MyM@world.std.com>
 <Pine.SGI.3.95.970916190053.19184D-100000@shellx.best.com>
 <dewar.874578577@merv> <EGpw57.8BI@world.std.com>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-09-20T00:00:00+00:00
List-Id: <comp.lang.ada>


Bob Duff said (I'm really really sure it was him :-)

<<It's true that all kinds of special situations are a pain, but I still
claim that the 2-pass algorithm required by Ada is more complicated than
the 1-pass algorithm of C++ and Red.  The 2-pass algorithm requires
*sets* of types to be passed up the tree, whereas in the 1-pass
algorithm you can pass a single type up the tree.

Yeah, I agree that's not such a big deal, and I certainly think the Ada
way is Good.>>


Right, it's not such a big deal, and Bob Duff's suggestion that the
concern for difficulty of compilation is what might motivate the choice
between the bottom-up overloading (first introduced in Algol-68) and the
both-ways overloading (first introduced in Ada 83) does not match the
history.

As almost always these days, the simplicity/complexity decisions are much
more focussed on users than on the implementor, especially in a case like
this where the implementation decisions are clear.

Certainly the designers of Algol-68 deliberately did NOT introduce the
both-way scheme, and this decision had nothing at all to do with concern
for ease of implementation (after all in Algol-68, just telling whether
two variables are the same type requires a sufficiently complex algorithm
that more than one PhD thesis has been written on the topic!)

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.

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.

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.