[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Common Lisp Subset
- To: common-lisp@SU-AI.ARPA, mathis@USC-ISIF.ARPA
- Subject: Common Lisp Subset
- From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
- Date: Mon, 2 Jun 86 21:24 EDT
- Cc: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA
- Supersedes: <860602212316.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>, <860602212339.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Mon, 2 Jun 86 11:44 EST
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 thought the purpose of a subset implementation was to make
it run on smaller machines, not to make it easier to write
I would also assume that at least a minimal amount of compatibility
would be desired. Eliminating lexical scoping eliminates an awful
lot of programs and techniques. It also means you can't look at
code and easily tell if it's legal; you have to expand every macro
that uses variables to see if it works by turning into a lambda with
I also thought a major motivation for a subset language is the so-called
"educational subset". Lexical scoping is the LAST thing I'd leave out
of an educational subset.
I would not leave object oriented programming out of the subset.
Then perhaps it should be an option.
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.
Agreed...if there is savings enough to make it worthwhile.
(I don't really know).
Finally, on the small machines for which this subset is intended,
declarations are crucial to performance, so they should be
allowed and exploited.