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/12
Message-ID: <EGEvqu.LKo@world.std.com>#1/1
X-Deja-AN: 271953638
References: <340ED5D8.2DEF6D3@ux4.sp.cs.cmu.edu> <dewar.873953300@merv>
 <dewar.873953773@merv> <3418390D.81B18056@ux4.sp.cs.cmu.edu>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-09-12T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <3418390D.81B18056@ux4.sp.cs.cmu.edu>,
Dean F. Sutherland <dfsuther@ux4.sp.cs.cmu.edu> wrote:
>I guess that Robert is correct for the general case of specifying inline
>expansion.  There's one specific case where I believe that the Gnal
>"spec" does indeed reasonbly "mandate" inline expansion (possibly even
>to Robert's satisfaction).

I doubt it.  (That is, I doubt it's to Robert's satisfaction.  It
certainly doesn't satisfy me.)

>Routines with nam binding for their formals would seem to "require"
>actual inline expansion.  (You'll recall from earlier in this thread
>that nam binding specifies re-evaluation of the actual object expression
>from the call site at each reference in the body of the routine.) 
>Treating this as (fully semantically checked) macro expansion is the
>obvious and straightforward way to achieve this effect.

I assume that "nam" binding is the normal Algol notion of by-name
parameter passing.  I believe that passing thunks (ie function closures)
was the expected way to implement it in Algol.

>On the other hand, I suppose that one _could_ do something with
>carefully produced function closures or some other such hack (I mean
>workaround) -- but I'm hard pressed to see why it would be worth the
>effort.

I'm not convinced it's easier to implement using macro-expansion.  And
thunks might in fact be more efficient in some cases.  Anyway, I'm not
sure why you consider it a hack/workaround, since it was, apparently, a
well-known implementation technique in the 1960's (before I knew what a
computer even was).

>A formalist might argue that, given the lack of a formal language
>definition, the inline expansion "mandate" is no more than strongly
>worded implementation advice.

I do so argue.

>...Of course, this would also imply that
>many common procurement specifications for compilation systems are also
>no more than strongly worded implementation advice...

Indeed.

- Bob