primitives, and dynamic binding

[MOON at SCRC-TENEX]

    Date:     11 November 1982 1302-pst
    From:     Earl A. Killian            <Killian at MIT-MULTICS>

    I am somewhat concerned about the lack of primitives in Common-Lisp.

I agree with you.  There is a problem, though, which is that if you specify
too many primitives you put a lot of constraints on the implementation.  This
doesn't apply to all of the specific points you brought up in your message,
though.

I think at this point the best thing would be to recognize that we are
specifying the first version of Common Lisp, and contrary to what it says
about stability in the front of the manual, there is going to be a fairly
large update in 6 months to a year.  It might be easier to put in the missing
primitives then.  Of course the danger of this is that each implementation
will have its own slightly incompatible primitives already by then.  But this
isn't really different from the situation we started with, with multiple
incompatible dialects.  If people are willing to be flexible we can adjust
our primitives to meet a common standard, or argue when techniques used in
a particular implementation rule out adherence to the proposed standard.

I do think it is important for the long-term success of the language that
as few of the underlying primitives as possible be concealed from the user.

    - Dynamic binding.  PROGV comes close to being a primitive, but is
      cumbersome and only works for the value cell of symbols.

This is a good case in point.  I would agree with you that there should be a
true binding primitive (although note that it would require adding locatives
to the language), however this would put fairly strong restrictions on
possible implementation techniques.  In fact the Common Lisp implementation
proposed for -your very own- machine can -only- bind the value cells of
symbols, because it uses deep binding, because it is a multi-processor with
a von Neumann memory.