ISO

[Jonathan A Rees <JAR@MC.LCS.MIT.EDU>]

    Date: 18 Dec 85  2216 PST
    From: Dick Gabriel <RPG at SU-AI.ARPA>

    We, at Lucid, have just gone through the hassle of putting into the Lisp
    package only those things in CLtL, while our own extensions are in the
    Lucid package. The Lisp package imports from the Lucid package. There
    is too much opportunity for unfindable bugs if you don't do this. In fact,
    I'm not sure we're gotten all the things in the right packages yet.
    If I were a real user, I would not stand for a CL that didn't do this.

I'm glad you agree.  Do you want to tell this to the mailing list or
should I?  I think it's very important.  Although taken all the way it
implies things like LAMBDA cannot have a definition as a function or
macro, and CAR cannot have a value, since of user A's code makes use of
the value cell of CAR, and user B depends on the value of CAR meaning
something interesting in the local implementation, A and B can't run
their code together.  The whole point of standardization is code sharing
right?  Wouldn't it be nice to be able to do it in the same address
space?

...Symbolics would have to retract their LAMBDA macro (or else, more
obviously, LAMBDA should become a macro in CL).

I would also like to have the home package of things exported by LISP:
defined to be LISP: .  Implementors will resist this, and it's less
important than the previous point, but I think it would be nice.  For
example, it makes shadowed symbol re-readable in different Common Lisp
implementations: suppose that Lucid CL's CAR is in the LUCID: package.
If you do
   (shadow 'car)
   (print 'lisp:car) 
you get LUCID:CAR.  Read the file in on your 3600 and you get "Do you want
to create a LUCID package," or, worse, one could exist which shadows CAR.

While I'm griping, what about the problem of package name conflicts?
Say I write a hairy program and call it LUCID, and of course put it in
the LUCID package.  I load it into your machine and it crashes Lisp.  We
need an agreed-upon domain-naming style naming convention, or
hierarchical package structure, or translation tables, or something.

    The mechanics of ISO will be to work on the ARPANET 90% of the time,
    meeting face-to-face very rarely. We are all very busy, and we are interested
    in top people. Please consider any invitation carefully.

Sounds doable.

    (Psst, maybe we can sneak in continutations!!)

If you think there's a mildly real chance of bringing in continuations,
I'll write a paper explaining what I know about how to implement them (the
pseudo-EGC hack, phantoms stacks, spaghetti, macaroni, etc.).  At the
very least they could have optional complex-number-like status, although
then why bother.

The only real problem I can see is defining their interaction with
UNWIND-PROTECT.  The only reasonable thing I can come up with is that
UNWIND-PROTECT should mean the same as GC-PROTECT or RECLAIM-PROTECT -
code which must get run at the soonest practically determinable point in
time that the stack frame is known to be inaccessible.  In the case of
random frames in the heap, only the GC is really capable of determining
whether a frame is still alive.  A Lisp which has "populations" can keep
track of all upwards continuations ever created so that users can
manually track them down without doing a GC, but this is pretty iffy
stuff, especially with all the unknowns of multiprocessors & concurrent
GC's.  ... Actually reclamation hacks arenn't really reasonable things
to specify, since they're semantically unsound (or complicated).  Any
ideas?