[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Dec 2 15:53:46 1995 
Subject:Re: reporting pop bugs (and pvars) 
From:Jonathan Cunningham 
Volume-ID:951202.11 

In article <49lif0$1ib@percy.cs.bham.ac.uk>,
A.Sloman@cs.bham.ac.uk (Aaron Sloman) wrote:

>jlc@sofluc.demon.co.uk (Jonathan) writes:
>
>> Actually, if you want a fast prototyping language, I don't understand why
>> you should have to declare any local variables at all (this criticism
>> applies equally to lisp and other dynamic languages). The compiler could
>> easily notice all the free variables in a procedure and declare them
>> as lvars _unless_ they were explicitly declared otherwise.
>
>That would not work for languages like Pop-11 and Scheme where there
>is no difference between an identifier holding a procedure as its
>value and an identifier holding anything else as its value. For the
>vast majority of `free' variables in a typical procedure are names
>of procedures defined outside the current procedure, and the above
>suggestion would stop them working completely, unless you declared
>all procedure names used in procedure P as global to P, which would
>be at least as tedious as having to declare lvars.
>
Good point, and one I don't recall hearing before.

It doesn't apply to typed languages, because you can make an exception
of procedure variables.

But there are three other ways in which this problem can be avoided (i'm
not concerned about trivial efficiency details, and only marginally
concerned with backward compatibility):

(1) Initialise local variables  with the value of the variable of the
same name which is in scope around the procedure. This is what happens
with dynamic variables anyway. I don't see why it couldn't be done
for lvars.

(2) Apply the rule only to free variables, not free constants. And then
make the default for procedure definitions to be that the defined
variable is constant. This doesn't exclude redefinition of procedures,
but you would have to cheat a bit during incremental development (i.e.
the code optimisation for calling constant procedures could not be
implemented - but this is different from making a variable syntactically
constant).

(3) Apply the rule only to free variables which are assigned to in
the body of the procedure. Variables which are accessed, but not
updated, need not be declared local.

And (4), combine (1) and (3), i.e. say (1), but implement (3) as an
optimisation. Actually, if local variable access is quicker than
global variable access, it could be that (1) is more efficient than (3).
Whatever.

The difference between (1) and (3) really depends on what you expect
to happen if you explicitly declare non-local access in nested
procedures (dynamic and lexically nested). But if you start doing
complicated things, you can be expected to pay attention to what you
are doing (cf lvars v. dlvars).

Regards,
Jonathan Cunningham