[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: several hundred ugly things
- To: Scott.Fahlman@b.gp.cs.cmu.edu, firstname.lastname@example.org
- Subject: Re: several hundred ugly things
- From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Date: Sun, 9 Oct 88 18:06:33 BST
- Cc: CL-Cleanup@sail.stanford.edu
- In-reply-to: Scott.Fahlman@edu.cmu.cs.gp.b's message of Thu, 06 Oct 88 20:51:36 EDT
There's some desire in some parts of ISO to make Common Lisp
"smaller". I'd just as soon see it done carefully -- rather than with
an axe. If you can think of several hundred things that could be done
to Common Lisp that would make it smaller and not as ugly, perhaps you
could help name a few?
Scott Fahlman replied:
> The point of my comment about hundreds of ugly things was that if we throw
> a few existing features out of the standard on aesthetic grounds, we would
> open the door to demands that we throw hundreds of other things out. I
> thought our charter was to introduce incompatible changes only if
> necessary, and not on strictly aesthetic grounds.
I agree with Scott's point to a large extent. Merely saying that
something "looks nicer" (or something of that sort) is not much
reason for an incompatible change in a group, such as X3J13, where
compatibility is rated very high. However, I think it may be useful
to say a bit more about what is happening in ISO. Of course, I can
give only my own understanding of what is going on.
There is indeed interest in having something smaller than Common Lisp,
but the reasons are not strictly aesthetic. One might argue a bit
about just how far "aesthetic" extends. Are simplicity, consistency,
and economy of basic concepts strictly aesthetic? I think they are
not, but it doesn't matter all that much: for we can always go back a
step and consider the implications for ease of learning and teaching,
for reasoning about programs and implementations, for ease of
implementation, the size and efficiency of applications, and so on.
These arguments might still be unconvincing in the end, but at least
we might agree that they are not strictly aesthetic.
Actually, I think it is rather difficult to find purely aesthetic
reasons at all. Even the "eliminate -IF-NOT functions" proposal
is not being advance on aesthetic grounds alone.
> But to address the question you raise...
> It seems to me that we could coherently divide the language into two
> levels: a kernel of necessary low-level functions and special forms, and a
> set of functions that can be straightforwardly implemented in terms of
> these kernel mechanisms. [...] Nobody would want to use a language
> that had just the kernel stuff, but making the division explicit
> might be of some use to implementors and to people doing formal
> analysis of programs.
It would almost certainly be useful for the ISO standard and, I would
think, for the ANSI one as well. A formal semantics, if given, would
presumably be for a kernel, perhaps even a smaller kernel than the one
needed for straightforward implementation of the rest. The EuLisp
group has long advocated layers of more or less this sort, though
Scott might consider their level 1 a subset of the unprincipled sort.
> I have never seen a principled proposal for a Common Lisp subset that
> includes some amount of non-kernel functionality.
I am inclined to agree. However, there might be different approaches
to devising the kernel. One apporach would be to identify a subset of
Common Lisp as it is now. But it might be possible to get a more
compact kernel by adding a few new primitives instead. I would not
like to rule out the latter approach in advance.