Re: BINDing unbounds

[Jonathan Rees <Rees@YALE.ARPA>]

    From:    Drew McDermott <Mcdermott>
    Subject: BINDing unbounds
    
    I realize this is unlikely to be acceptable...
    
Right.  The problem is, what is the BIND macro supposed to expand into?
Right now,

    (BIND ((X 5)) (FOO))

does something similar to

    (LET ((TEMP NIL))
      (LET ((EXCHANGER (LAMBDA ()
                         (EXCHANGE X TEMP))))
        (BIND-HANDLER EXCHANGER (LAMBDA () (FOO)))))
        
and BIND-HANDLER, in effect, is

    (DEFINE (BIND-HANDLER P1 P2)
      (P1)
      (BLOCK0 (P2) (P1)))
      
The problem is, how to make the first EXCHANGE not bomb out.  It has
to save the old value of X, which doesn't exist.  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.  And I don't think this uncleanliness is warranted.

Another semantic problem is that if you have something like

    (LOCALE ()
      ...
      (LOCALE ()
        ...
        (BIND ((X ...)) ...)
        ...)
      ...
      (LSET X ...)
      ...)
      
then things start becoming very strange.  Does X get bound in the
outer locale or the inner one?  Of course SET has the same problem;
this has been discussed before.  That SET in 2.7 only gives a "warning"
and not an error is by a special dispensation which is not available
to BIND because BIND is not primitive.

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.

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

Sorry if this change is causing you problems, but I think it's a
necessary one.