Re: BINDing unbounds

[Drew McDermott <Mcdermott@YALE.ARPA>]

    ...The only way to deal with this would be to introduce a new
    "subprimitive" special form into the interpreter and
    compiler, one which got the value of a variable without
    producing any error if the variable was unbound.  This was
    pretty easy to do in version 2.6's evaluator, but is harder
    in 2.7's.

Such a subprimitive is what I had in mind.  I pictured something that
would get the value cell for the variable in the current environment;
surely such a thing exists already.  Then if the cell contained a "nonvalue,"
NIL would be placed into it instead.   Why is this subprimitive harder to
write in 2.7?

    ...  things start becoming very strange.  Does X get bound in
    the outer locale or the inner one?

    If you say (RET) when the unbound-variable error occurs, then the
    recovery is graceful.  You can then edit your source code at your
    leisure.

There seems to be a contradiction here.  What happens when you type
(RET NIL)?  I pictured NIL being used as though it had been found in
a value cell.  That is, in your EXCHANGER code, the NIL would go into
TEMP, and no one would know, after BIND returned, that the NIL hadn't
been there all along.  It seems to me that if this is what happens,
then it ought to be possible to make it happen without the user typing
anything.

I suppose in this case the variable gets bound in the innermost locale.
Well, why not advertise in the manual that using BIND on an unbound
variable binds it in the innermost locale?

   I thought that NISP had a SPECDECL form for declaring global variables.
   Couldn't this do the top-level initializations also?

Yes, it can.  In fact, when I first saw the new BIND restriction, I
guessed that very few of my special declared variables were not initialized.
I have discovered that about 15% of them are uninitialized, and it is
painful to find them.  It is even more painful finding all the NISP
sources on various machines and making these little changes.  Note that
running code through the compiler does not suffice to find them, since
the compiler can't tell if a BIND is legal or not.  Usually hunting
for SPEC will find all of them, since I never leave a special variable
undeclared.

There is actually a good (if not overwhelming) reason for leaving a variable
uninitialized if its global value is never accessed.  It helps catch places
where a function is called by someone who failed to bind a dynamic variable
that was needed.  I had more or less unconsciously made sure that every
variable that didn't have a meaningful global value didn't have any
global value, and this has come back to haunt me.

Under the new regime, the variable will have value NIL
or something, and such bugs will go undetected a little longer.

-------