Common Lisp Subset

[mike@a]

    Date: Sat, 24 May 86 12:34:54+0900
    From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>

            A Common Lisp Subset Proposal

    
                    Masayuki Ida
            Assoc.Prof, Aoyama Gakuin University
            Chair. Jeida Common Lisp Committee
   
            .....    

I disagree mostly with this proposal. I think a good slim subset is
important. However, I take the position that what we should leave out
is lexical scoping. This does NOT mean we should regress to dynamic
scoping, but that the subset allow only "local lexical" scoping.
I.E., free vars in lambda's or defuns MUST be globals. Code which
works under this restriction will always work under full lexical
scoping. The subset interpreter should also have this scoping.

One major win here as a subset is that you can still allow
tagbody and go. But the go targets must be known and local.
There is no implicit "throw" caused by interactions of go-targets
and lexical scoping. This is the only change to Common Lisp which
I believe will make compilation significantly easier.

I would not leave object oriented programming out of the subset.
If for example CommonLoops were adopted as a standard, I would
take the subset which omits class "class".
CommonLoops will allow programmers to extend the 
subset with the features that they need in a syntactically
pleasing and upwardly compatible fashion. I.E., if the subset
doesn't include complex numbers, but a user needs them, it is
easy in commonLoops to overload the arithmetic and other
operations to do type dispatch for complex numbers. The same
is true for rationals, bignums, etc. etc. 

The goal is to strip out most of the built in types which can be
constructed or provided as part of a library.  Hash tables,
fill-pointer'ed arrays, extended arithmetic types, etc.  all fall in
this category. Then programmers can use the object oriented feature
to build their own implementations of the needed types.
    
Finally, on the small machines for which this subset is intended,
declarations are crucial to performance, so they should be
allowed and exploited.

...mike