The many faces of NIL, or special cases have to be handled specially.

[Andy Freeman <andy@Neon.Stanford.EDU>]

>Now one can point out that the obvious fix is for the Chaosnet code to
>bind *PACKAGE* to some package known to be reasonable around the call to
>READ.  But I contend that a system should be designed so that such bugs
>never happen in the first place.  And it seems to me that the obvious
>mechanism for accomplishing this is only our old friend, lexical
>scoping.

I ran into a similar problem, but I think the correct solution lies in
print.  In the situation described, the program was correct iff the
printer and reader were using compatible packages, as the default
package says how to interpret symbol shorthand, that is, symbol names
that don't include their package.  In the case I ran into, and it
seems this case as well, print assumed that NIL always meant
global::nil, so it didn't bother to check whether it did in its
*PACKAGE*.  (Of course, if it had printed () instead, all would have
been okay, but there are other special symbols that don't have an
unambiguous shorthand in non-symbol-name syntax.)

Getting back to the reason for the tangent, the discussion of dynamics
(that name grates on me too), I think that rpg's message brings up
something important.  I think the dynamic proposals have used the
assembly-language-style wall to hide something.  I think that
something is something about the nature of control-flow, as dynamics
are fundamentally a tool for associating values with control, and
control has been something of a second-class citizen up until now.

Can the first-class environment people help here?

BTW - I like much of rpg's proposal, but I don't like the idea that
dynamics can only be created in the global environment.  To that end,
I'd like to see:

(CALL-WITH-DYNAMIC obj thunk)				[Procedure]

Invoke thunk in a new dynamic environment that is nested within the
current dynamic environment and contains a new dynamic whose initial
contents are the value obj.  The thunk is called with that dynamic as
its argument.  This dynamic environment has precisely the same extent
as the invocation of the thunk and is thus captured by continuations
created within that invocation and re-established bythose
continuations when they are invoked.

make-dynamic makes me a bit uneasy.  I think I'd prefer something
along the lines of a top-level define.  (Perhaps that analogy can be
stretched to include a meaning for define-dynamics at other levels.)

-andy