Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Is this the end of the lisp wave?
Message-ID: <3971@skye.ed.ac.uk>
Date: 18 Jan 91 13:32:13 GMT
References: <127724@linus.mitre.org> <5569@turquoise.UUCP> <3954@skye.ed.ac.uk> 
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 90

In article  alms@cambridge.apple.com (Andrew L. M. Shalit) writes:

>   There isn't any reason, other than historical, why
>   Common Lisp couldn't be presented, and even implemented, in a more
>   C-like way, as a language plus libraries of procedures and data types.

>Offhand, I disagree with this.

Well, for one thing, I don't think you're taking history enough
into account.  The large, monolithic Common Lisp systems we all
know and love were constructed that way for reasons that I would
say are essentially historical.  Implementors from a different
background and with different experience of Lisp and different
expectations of how it would be used might well have implemented
Common Lisp (the very same language) in a significantly different
way.

You later say that Common Lisp implementations have a "very tangled
call tree".  Now, maybe that is true.  But it's not necessary to
implement CL that way, and it looks like you haven't looked at any
implementations to see if it's even _been_ implemented that way.  (Not
that that would settle the matter, since I was talking about how the
language could be implemented, not how it was implemented.)

Of course, there's no doubt that the kernel of CL is bigger than that
of C.  But that doesn't mean that a separation between kernel and the
rest can't be made.

>It's true, Common Lisp has many features.  But these features are
>often used to implement other features.  In other words, a CL
>implementation has a very tangled call tree.  It's hard to find
>portions of the language which could be removed.

There seem to be a fair number of people (especially in the UK?) who
think this is so and, moreover, must be so.  However, after citing
format, packages, and maybe multiple values they tend to run out of
examples.  Perhaps there are many more examples, but it requires some
careful investigation to determine just how far the problem extends.

My feeling is that the impression of a tangled language is due at
least in part to how CL has been presented, and -- I claim -- it could
be presented differently.  It is possible to extract a coherent subset
of CL, at least conceptually.  (Since I've done this a couple of
times, I think I have fairly good reason to think it _can_ be done.)
Of course, the language would be better in this respect if it had been
one of the goals of the design, but it is nonetheless possible to go
further in this direction than one might suppose.

>                                                 If you put APPEND,
>ASSOC, MEMBER, REVERSE, and MAPCAR into a separate module (as EuLisp
>does, I believe) chances are that every implementation is going to
>have them in the kernel anyway.  

That may well be so (except for ASSOC), but you need it to be so
for more than five functions for this to be significant evidence 
for your claim that it is difficult to untangle the language.
Moreover, the kernel needn't use function in their full generality.
Most likely, MEMQ is used rather than MEMBER, for example (and
the MEMQ calls perhaps compiled away).

BTW, Prolog implementations have append/2 in them, and yet users have
to write it themselves or load it from a library of they want to use
it.  So it's certainly possible to think of a language as not having
append even though it's "really" built-in.

>Hash-tables are used to implement packages.

Not necessarily.

>Format is used for error messages and other system io.

This is the most cited example, and it's not a very good one.  Many
format calls can be compiled away into calls on much simpler functions.
Moreover, system messages can be (and almost certainly are) written to
use only a subset of format's capabilities.

>Sequence functions are used all over the place, etc. 

Really?  Remove-if, perhaps?  There are a number of functions (and not
just sequence functions) that aren't used all over the place.  Look at
KCL, for example, where the more central functions are written in C
while others are written in Lisp.  And it would be possible to reduce
the size of the C kernel if this were felt to be sufficiently
desirable.

Remember too that libraries can be implemented, or connected to the
Lisp system, in various ways that reduce the impact of procedures not
actually in use: e.g., autoloading, shared libraries.

-- JD