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: "Dean F. Sutherland" Subject: Re: The Red Language Date: 1997/09/11 Message-ID: <3418390D.81B18056@ux4.sp.cs.cmu.edu>#1/1 X-Deja-AN: 271651292 References: <340ED5D8.2DEF6D3@ux4.sp.cs.cmu.edu> <199709051335.PAA25952@basement.replay.com> <34102DF5.36D589F1@ux4.sp.cs.cmu.edu> To: Robert Dewar X-Priority: 3 (Normal) Organization: Carnegie-Mellon University Newsgroups: comp.lang.ada Date: 1997-09-11T00:00:00+00:00 List-Id: 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). 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. 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. 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. Of course, this would also imply that many common procurement specifications for compilation systems are also no more than strongly worded implementation advice... Dean