[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jan 20 12:26:22 1993 
Subject:Re: lvars and standards (was: Re: List and Vector Syntax) 
From:Steve Knight 
Volume-ID:930121.04 

Answering my request for clarification, Brian discusses the following
break-loop scenario:

> Procedure A, with local variable LA, invokes B, with local variable LB.
> An error occurs inside B.  We are now in a break loop.  In what environment
> are we working?  With lexical scope I can see three possible answers:

None of the three suggestions (below) were what I had in mind.  The more 
"obvious" answer pops straight out of the denotational semantics.
There is a single binding environment in both lexical and dynamic 
binding at the break point.  It is defined by the association between
all the variables in scope at that point and their values.

For completeness, I'll review Brian's suggestions.  However, I'll repeat
an earlier remark that has probably been lost in the general drift by
now.  It is easy to implement access to the binding environment when
dynamic binding is used.  It is possible (but awkward) to do this with
lexical binding.  Few, if any, systems implementing lexical binding
also implement access to the binding environment at a break point.  All
systems implementing dynamic binding do.

OK, having got that qualifier out of the way, here's Brian's first
suggestion.

> 1.  We're in a brand new environment, with no local variables at all.
> To get to LB you have to say "back up a frame on the stack"; to get to
> LA you have to say it twice.

My feeling is that this is motivated by watching the average lexical-debugger
in the street.  My programming languages work this way inside a break
loop.  Highly undesirable, not exactly necessary though.

> 2.  We're in B's environment.  Now LB is available in the ordinary way,
> but LA still isn't.

This is where Brian departs from the usual view of lexical binding.
Inside B's environment, LA is certainly visible.  Whether B makes
no reference (or makes a reference) to LA has no effect on scoping.

I would suggest that this is indeed the natural solution, exactly the
same solution as is adopted by dynamic-debuggers (if I may coin a phrase).
At the break point, we are inside B's scope able to access and update
all variables that are in scope.  For shadowed variables we need special
mechanisms for access -- exactly the same as for dynamic binding.

> 3.  Break loops have different scope rules from those of the normal
> language; LA and LB are both available using the usual notation for
> variables and without any extra commands to switch frames.  In effect,
> break loops obey dynamic scope.

The above remark's serve for this case, also.

It appears that Brian's argument is that access to the variables
that are in scope at the break point is predicated on dynamic binding.
I am contending that it is merely a matter of implementation.  To 
consolidate my position, I shall outline an implementation that 
a system using lexical binding (such as Pop) can exploit to achieve
the effect outlined.

Assuming we are in debug mode and therefore prepared to tolerate a minor
efficiency cost, do the following.  For each declaration and assignment
to a lexical variable, create a "secret" dynamic variable that is
dlocalised and assigned to immediately prior to the lexical variable.
Inside the break loop, access to any lexical variable is transformed
into the associated "secret" dynamic.  In any pushable lexical scope,
the "secret" dynamics of any captured lexicals must be re-dlocalised.
This latter step deals with the capture of environments through
lexical scopes.

This establishes a dynamic environment with exactly the right properties
for the break-loop.  It is indistiguishable in properties from a 
dynamic-break-loop.  It correctly implements the scope under a policy
of lexical binding, too.

Where I am obliged to agree with Brian is that this kind of break-loop
is routinely available in systems that use dynamic binding and rarely,
if ever, available in systems using lexical binding.  This supports
his original claim that systems that exclusively use dynamic 
binding have, in practice, some advantages over those that incorporate 
lexical binding.  And I concede this.


On the second issue of whether dynamic binding is advantageous because
you can treat lists as procedures, I shall duck out.  It merits
its own lengthy discussion and the previous comments are too long already.
If I find the time, I might start up a new base note with this as 
its underlying theme.  (e.g. Using parse trees as procedures considered 
harmful to children.  The Programmer General says that using lists
as procedures can permanently damage your computer science. Etc etc)

Steve