issue PROCLAIM-LEXICAL

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 20 Jan 89 15:53:12 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    My gut feeling on this issue is that people would be willing to vote
    it in, provided that we can guarantee that you would never have to
    access the symbol's global value when there is a special binding of
    the variable.  I believe this was the purpose of the amendment that
    was accepted (stating that "it is an error" to specially bind a variable
    that has been proclaimed lexical), but there are still some other
    possible cases.

Yes, I believe that was the unstated goal behind all of the proposed
amendments.  I also believe that it would take several additional
amendments beyond the two proposed to completely close this "hole."
I agree with Kent that trying to close this "hole" is a very, very bad
idea.

I believe that the reason people have this goal is not at all an issue
of desired language semantics, but instead that they believe it would be
too difficult in a shallow-bound implementation to allow access to the
global value in the presence of special bindings.  I used to believe
that too, but I figured out that the implementation expense can be very
small.  Here is why:

On stock hardware, the implementation of special variables is unchanged
except that associated with each shallow binding cell is a flag that
says whether a SPECIAL binding has ever been performed.  This flag can
be set by the loader when a function that might make a SPECIAL binding
of that variable is loaded, and also must be set by PROGV.  The
implementation of global LEXICAL variables checks this flag; if clear
(as it will be in the vast majority of cases), use the shallow binding
cell.  If the flag is set, global LEXICAL access must search the SPECIAL
binding information to find where the global value has been saved, a
pleasing symmetry with deep binding.  Note that this implementation puts
100% of the performance cost on the new feature, and in the majority of
cases the performance cost is only two instructions to verify that the
flag is clear.  In fact, in an implementation that can patch compiled
code, the cost is zero because global LEXICAL accesses can be compiled
optimistically and in the event that the SPECIAL binding flag gets set,
they can be patched to call the slow subroutine.  Of course in a deep
bound implementation, global LEXICAL access just accesses the global
cell and there is no cost.

On machines with invisible pointers, the implementation is to have a
global SPECIAL cell and a separate global LEXICAL cell, linked together
by an invisible pointer from the SPECIAL cell to the LEXICAL cell.
SYMBOL-VALUE and SET follow the invisible pointer, but binding does not.
As desired, the shallow bound cell shares with the global LEXICAL cell if
and only if no special bindings are present.  Of course you only create
these value cells on demand, so for the vast majority of symbols that
are not used in both the SPECIAL way and the global LEXICAL way, you do
not pay the overhead of having two cells.

My conclusion is that I am strongly opposed to any attempt to amend this
proposal to restrict simultaneous use of special and lexical variables.
It would be much preferable not to pass this proposal at all than to 
pass it in messed-up form.

    Date: 23 Jan 89 21:45 PST
    From: masinter.pa@Xerox.COM

    ....The reason for GLOBAL is primarily for performance
    -- it is a deep-bound implementation, and references to GLOBAL variables
    are significantly faster.  I don't think Medley users would get along OK
    without it.  I don't think users of *any* deep-bound implementation would
    get along well without some equivalent.

I think the idea that deep-bound implementations can only work well when
there are GLOBAL declarations is misguided.  What does GLOBAL really
mean?  I claim it is a -declaration- by which the programmer promises
not to make any special bindings.  But the implementation is perfectly
capable of determining for itself whether there are any special
bindings, without any help from the programmer.  Comparable to what I
suggested above for LEXICAL variables in shallow-bound implementations,
accessing a SPECIAL variable in a deep-bound implementation can easily
check a flag indicating whether any bindings have ever been performed.
In the usual case where there are no bindings, the run-time cost is
zero, as I indicated above.

    Given the likelihood of PROCLAIM-LEXICAL:LG failing, I suppose I *would*
    like to see a GLOBAL proclaimation made standard, since it doesn't seem to
    hurt shallow bound implementations and is important for deep-bound
    implementations. If "it is an error to attempt to bind a variable
    proclaimed or declared GLOBAL", if you declare it or proclaim it GLOBAL,
    you can't have any bindings, whether such bindings would be lexical or
    special. In that sense, a GLOBAL variable could be thought of as a subset
    of SPECIAL variables which share the "not bindable" property of constants.

In the immortal words of America's last truly great president, we could do
that but it would be wrong.

I think we should pass PROCLAIM-LEXICAL as it was before it was amended.

    Date: Wed, 25 Jan 89 16:26:36 GMT
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

    As I understand it, the problem faced by deep-bound implementations
    (of special variables) is that they don't know whether there are
    any bindings or not and so have to look before fetching the global
    value.  But I think it's OK for that to happen to variables that
    might have special bindings; what's wrong is to have to do it even
    though the programmer knows there will never be any bindings.

Right, that's what I was trying to say above.

    I still prefer LEXICAL.  LEXICAL sunsumes all the reasonable uses
    of GLOBAL.

I feel the same way.