Language 'standards' for LispOS

[Henry G. Baker]

Re Common Lisp, Scheme, etc.:

I thought that I would just summarize my position re the use of
'standard' languages for SW development, including LispOS.

A language standard is a relatively good thing when it regularizes
existing usage.  Thus, instead of having every shoe manufacturer
utilize different schemes for specifying shoe sizes, most
manufacturers conform to one scheme.  This isn't perfect, as women
(e.g., my wife) keep reminding me, which is why one still has to try
on those shoes.

Building a system in a programming language is like running a marathon
in a pair of shoes.  You _very_ quickly become aware of every little
quirk in those shoes.  Having programmed quite substantially in Common
Lisp -- especially CL84 -- I have become acutely aware of a number of
quirks in this language that have rubbed and chafed at me through the
years.  I suspect that some of you have been rubbed and chafed by CL,
as well.

As the C language people have pointed out through the years, the
_literature_ of a language is more important than the language
standard.  At least in the early going, C was defined more by its
literature -- the Unix system -- rather than by any 'standard'.  This
system worked rather well, since the sum total of the Unix system
investigated nearly every dark corner of the language.

I don't know what could be considered the 'literature' of Common Lisp,
but whatever it is, we don't want to cause irreparable harm to it.
Notice that I didn't say it wouldn't require _some_ changes -- e.g.,
packages or declarations.  Similarly, moving from K&R C to ANSI C
required substantial changes in the matter of declarations, but people
didn't seem to mind this, since it improved reliability of programs
quite substantially.

As I have pointed out in previous postings, certain irritations with
Common Lisp have made me suggest what appear to be rather fundamental
changes to CL.  In particular, I have suggested a whole new class of
datatype issues -- mutable v. immutable v. linear.  However, I claim
that these don't change the _literature_ of CL, since most people were
already utilizing these concepts when thinking about CL data
structures.  All I have suggested doing is to formalize this thinking
and make it explicit to the compiler and runtime system.

The primary reason for making these issues primitive is to _allow_ the
whole of CL to be built _in_ Lisp, and still make it _efficient_.  The
resulting CL may not be 100% CL, but that doesn't bother me so long as
any important CL _program_ can be run with minimal modification.

As I have pointed out before, although I like very much the Xerox MOP
_way_ of implementing CLOS in itself, I have some grave reservations
about some of the details.  In particular, the existing MOP/CLOS
structure provides absolutely no support for _immutable_ objects like
numbers, which makes it impossible to build the CL number tower
_within_ CLOS.  This is _unacceptable_.  Unfortunately, this is going
to require some substantial surgery to MOP, since it _assumes very
deeply_ that every object is mutable.  I think that this can be fixed
through the use of 'linear' objects which can be 'frozen' after
initialization into immutable objects, but it will require going
through the MOP and revising substantially the way that objects get
built.  I would suggest 'warming up' by doing this in 'Tiny CLOS'
first, before doing it in real CLOS.

Another area of concern is 'unwind-protect', which I believe is too
'high-level' to correctly support a reflective architecture.
Unwind-protect also interacts strongly with 'linear' types, so this
has to be done correctly.

The whole argument-passing stuff in CL is too baroque, and needs to be
factored into some much simpler primitives which can still implement
things like optional/keyword arguments and multiple returned values
moderately efficiently.  Please note that when CL first came out, a
number of older lisps offered CL compatibility packages which
implemented the more complex CL arg/value stuff on top of a simpler
lisp.  I suggest that we do the same thing, but this time we get to
design the more primitive lisp ourselves.

One remark about compiler optimizations.  The CL committee, even with
all of its experienced members, outfoxed themselves when it came to
optimizations.  They assumed that it would be possible to do all these
wonderful optimizations -- most of which never happened!

The C language, on the other hand, _never_ assumed the existence of
sophisticated optimizers, and for its first 10 years or so, it never
had them.  In retrospect, this was definitely the right decision.

Although a sophisticated type inference mechanism integrated with a
macro facility would be a nice goal, I don't think that it is wise to
hold up the LispOS project assuming that such a thing will happen
quickly.  However, I do think that macros and compiler-optimizers are
_good things_, and insofar as they can be utilized, that would be
great.  Of much greater importance, IMHO, is having access to a
reasonably straight-forward compiler that can be readily modified when
a crucial optimization becomes important.  _It is much better to fix
the compiler ONCE, than to have 50 people continually tripping over a
compiler bug and/or lack of optimization_.  Anyone who has had to do a
project with a buggy compiler that couldn't be fixed will know very
well what I mean!

-- 
Henry Baker
www/ftp directory URL:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html