Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!seismo!mcvax!boring!lambert
From: lambert@boring.uucp (Lambert Meertens)
Newsgroups: net.lang
Subject: Re: and if you put this in your language ...
Message-ID: <6847@boring.UUCP>
Date: Wed, 26-Mar-86 18:13:52 EST
Article-I.D.: boring.6847
Posted: Wed Mar 26 18:13:52 1986
Date-Received: Sun, 20-Apr-86 07:32:15 EST
References: <1187@mmintl.UUCP> <800009@ccvaxa> <6843@boring.UUCP> <87@cstvax.UUCP>
Reply-To: lambert@boring.UUCP (Lambert Meertens)
Organization: CWI, Amsterdam
Lines: 56
Keywords: Refinements
Apparently-To: rnews@mcvax

In article <87@cstvax.UUCP> db@cstvax.UUCP (Dave Berry) writes:

> In article <6843@boring.UUCP> lambert@boring.UUCP (Lambert Meertens) writes:
>> ...
>> Some languages have "refinements", which are somewhat like macros but they
>> really are part of the language and do not get expanded by a preprocessor.
> 
> Isn't it simpler to have a parameterless procedure with no local variables
> and a compiler that recognises such things?  Maybe with pragmas giving the
> user control over the optimisation if you want it?  

Parameterless procedures are fine provided that:
1) The language allows to define procedures that are local to a given
   procedure and which inherit the environment;
2) You can postpone the definitions of the local procedures.

Under these conditions, there is in fact no discernible difference between
refinements and these procedures, except maybe for a lighter syntax for
refinements.

Condition 1 is vital, but is not fulfilled by ELAN, ABC or SETL (if I
remember correctly), nor by C and many other languages.  All procedure
definitions are on the same, global level.  Since the refining procedure
has to be able to modify the environment, it cannot then be parameterless.
(Unless procedure variables have no local scope, but that is too awful.)
Using parameters would be too awkward, especially since later data
refinement in the top-down style can change the parameters to be passed.

Condition 2 is not vital; however, it is awkward if you have to return to
the top of the body for declaring the procedure.  The same is true for
languages that require introductory declarations for variables, but in that
case programmers have to put up with it since they have no choice.

> Procedures handle sequential abstraction fine.  Want you seem to be after
> is greater control over the way they're implemented.  You don't have to
> allocate a new frame on the stack just because you call a procedure, if
> there is nothing to put in it!
> 
> Maybe I've spent too long programming in functional languages, where you
> have to do things like this (and tail recursion optimisation similarly)
> to get decent performance.

As a language *designer*, I am not particularly interested in how
procedures are implemented.  As a language *user*, I mainly wish more
compiler writers would recognize the importance for people trying to
program in a decent style of optimizations like replacing tail recursion by
a jump, and in general of fast procedure entry/exit.  Given the usual heavy
overhead, the only control over the implementation I have sometimes longed
for was an option advising the compiler to generate inline code for a
procedure.

-- 

     Lambert Meertens
     ...!{seismo,okstate,garfield,decvax,philabs}!lambert@mcvax.UUCP
     CWI (Centre for Mathematics and Computer Science), Amsterdam