Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!ut-sally!utah-cs!utah-orion!shebs
From: shebs@utah-orion.UUCP (Stanley Shebs)
Newsgroups: net.lang.lisp
Subject: Re: 3-Lisp
Message-ID: <139@utah-orion.UUCP>
Date: Sat, 19-Jul-86 15:27:51 EDT
Article-I.D.: utah-ori.139
Posted: Sat Jul 19 15:27:51 1986
Date-Received: Sun, 20-Jul-86 06:28:26 EDT
References: <137@utah-orion.UUCP> <1405@well.UUCP> <1000@kuling.UUCP> <1450@well.UUCP>
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Organization: University of Utah CS Dept
Lines: 215
Keywords: Lisp, 3-Lisp, purity, reflection

(I wouldn't bother, but replying to flames is easier than working on a
thesis...)

In article <1450@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes:

>I have read Padget et alia's paper.  Since it has not yet been
>officially published and we were requested not to quote it or discuss
>it before then, I will abide by the authors' wishes and defer discussion
>of the paper _itself_ until its publication.

No such request came with my copy.

>There are open questions, which
>is why the ISO/EuLisp is still a draft, but these are not "holes".

I consider an "open question" in a language design to be the same as
an "open hole";  a "settled" or "closed" question is a "closed hole".

>In my draft of the ISO standard, dated June 1, I can find no reference
>to an "explicit environment object".  Even if there is such a data
>type in versions which I have not seen, it is hardly a radical or
>untested idea; it goes back to the earliest days of LISP.

It's not been standardized on, but both Eulispers and Common Lispers
have been talking about it for awhile.  The hard part is having environment
objects that are more sophisticated than the simple alists that UCI Lisp
allows in certain contexts.  For instance, the "environment" in a compiled
program includes the machine's stack, which almost certainly includes
non-Lisp objects.  If one were to make an ordinary data object out of this,
it would be necessary to ensure that such things are insulated from the
Lisp world.  Also, an explicit environment object would be pretty useless
unless you could install it directly, but I don't know of any Lisp that
can take such a data structure and reinstall it into the machine's stack.
I'd be glad to hear of any implementation that does this efficiently.

>The standard point out in graphic detail many of the problems of
>CL, at one point using the word "pornographic" to describe the number
>of ways in which a symbol can be used.

Well, after reading large piles of literature, I've come to the conclusion
that Europeans are, on the whole, considerably better flamers than Americans.
I can't think of any language design (even UCI Lisp) anywhere that I would
stoop to describing as "pornographic", and especially not in print!

>This is a very open issue [in the Eulisp draft],

"open issue" == "open question" == "open hole".

>Mr. Shebs seems to have a basic inability to distinguish between
>forests, trees and shrubs.  He is either unwilling or unable to
>understand and address the issues.

What issues are you referring to?  If it's language design issues,
I'm not particularly interested - arguing whether Eulisp or Common
Lisp is "better" is akin to arguing whether Pascal syntax design
is better than C syntax design.  It's just too trivial.  On the
other hand, arguing about the effect of designs on implementations
is valid, but it's very hard to know what the TRUE effects are (see below).

>He defends Common LISP with a nearly religious zeal, [...]
>Misstatement fills out his repertoire.  Technical content
>is either totally lacking or impossible to find among the derogatory
>adjectives.

I thought Usenet was not the place for ad hominem?

Mr. Jacobs' insults aside, I must admit to finding myself in an uncomfortable
position defending a large committee-designed language.  Logically,
I should defend Cobol, PL/I, A*a, and Algol-68 also.  But there's
a deeper issue, which is about the notion of "language design", and
about which there is some confusion, judging by some recent postings.
The misconception is about "right" and "wrong" designs.  This is totally
meaningless.  A language design is just that - a design.  Talking about
"right" and "wrong" features is like saying the design of the Golden
Gate bridge is "right" and that of the Verrazano Narrows Bridge is
"wrong", or that Jackson Pollock paints "right" and Leonardo painted
"wrong".  Language design is fundamentally an emotional process, if
done by one person, and fundamentally a political process, if done by
a committee.  There are really no technical or logical means for deciding
on the names of functions, or how variables will be scoped, or how
large the language will be.  I am completely and perfectly free to
design a language in which "+" operates normally on numbers, but for
which (+ "jjacobs" "sshebs") returns "flame".  NO ONE can tell me this
is a wrong thing to do.  It might be strange, or confusing, or disapproved
of by the Knights of the Lambda Calculus, but you can't *prove* it to be
incorrect.

This is not to say that a design decision does not have consequences!
On the contrary, painters and architects and language designers operate
under a great many constraints - language designers maybe more so than
the others, because a language design will have an enormous numbers of
(opposing) consequences, in space vs time performance, length and complexity
of source code, compatibility with other languages, and so forth.
The study of these consequences is a fascinating but extremely complicated
business, and has never been formalized (now we're getting into my thesis
topic!).  To use my example, extending the domain of "+" might (under certain
circumstances) slow it down, or make the language manual longer, or
complicate the possible representations for strings and numbers. (It
will certainly annoy some people, but that's not a technical consequence.)

In the process of doing my research, I have had the opportunity to look at all
of this at leisure, and am now much more aware of the subtleties involved,
and in particular many of the technical consequences of Common Lisp design
decisions.  Some of them are surprising, others merely obscure.  Things that
superficially appear to be "bad" (for instance function protocol) have a
great many pleasant consequences, while other things that are superficially
"good" (for instance the traditional Lisp macroexpansion) have some unpleasant
consequences.  In general, feature X of language Y will have both good and
bad consequences, and the language designer must weigh these against each
other (once again, a non-technical process).  It is not inconsistent for
me to say "the reason for feature X of language Y is that Z; however, W" and
at the same time to say "I really hate feature X".

Now for an application:  many people claim that Common Lisp's division
of functions and values is "wrong", but many other people consider it to
be "right".  Of course, neither is the case.  Merging of functions and
values simplifies some programs, but it can lead to name conflicts, which
is a traditional bane of Lisp.  The issue of *efficiency* of separate function
cells is extraordinarily complicated;  literature search shows dozens, maybe
even hundreds of algorithms to take into account.  Someone (not me!) could
write an interesting dissertation that formally analyzes these methods.

I mentioned politics as being the chief activity of design by committee.
Eulisp has the luxury of relatively little political pressure being exerted
on it from outside.  That has some advantages for language design, but I
wonder if it means that nobody really cares, and that Eulisp will be ignored
by everyone outside of a small European community.  The same interests
in the USA that influenced the Common Lisp designers probably will not
rewrite all of their software to suit Eulisp, so unless something dramatic
happens, we're heading for a situation analogous to Fortran vs Algol in 
the 60s.  It's sad, but politics doesn't interest me much anyway.

Finally, just for the record, Common Lisp is not my favorite language.
Those laurels are shared between the logic programming language MRS developed
by Mike Genesereth and hist students at Stanford, and the equational language
OBJ2 developed by Goguen, Meseguer, and others at SRI.  I believe that the
future of computer languages lies in the direction of those which subsume
several programming paradigms (functional, logical, and object-oriented at
least) in a common computational framework.  In addition, the distinction
between knowledge representation and algorithm encoding will be extremely
fine.  Lisp won't fade away - it will end up like Fortran, with a base of
users dedicated to a stable language, but little interest from the research
community.

>There are no accepted subsets of Common
>LISP, as Mr. Shebs himself has previously stated.

Since I've been involved in studying and proposing plausible subsets of
Common Lisp for nearly two years, I doubt that I would oppose the idea
of subsets of Common Lisp!  What *is* the case is that most subset
proposals get shot down because they inevitably exclude someone's favorite
feature, and then that someone decides that the full language is preferable
to the subset, and withdraws real support from the subset.  Politics...

>Since Mr. Shebs takes a great deal
>of credit for PCLS, he has nobody but himself to blame for it's [sic]
>deficiencies.

That's true.  Understand, however, that PCLS must operate under a large number
of constraints.  The goals of PCLS were: 1) to embed a Common Lisp subset
in PSL, 2) to avoid making massive changes to PSL, 3) to not compromise
the efficiency of PCLS relative to PSL, 4) to investigate the methods
and problems of Common Lisp implementation, and 5) to make PCLS available
to PSL users to ease the transition from PSL to Common Lisp.
Goals 1, 2, and 5 together mean that we must retain complete
compatibility with PSL, sufficient that existing PSL programs will
run in PCLS if one stays in the "psl" package.  Another desirable consequence
is that PCLS comes up on the dozen different PSL systems fairly easily.
To satisfy goals 2 and 3, we had to implement all compiler optimizations
as source-to-source transformations - we couldn't touch the PSL compiler.
Fortunately, we were able to come up with some transformations that optimize
most PCLS programs to the performance of their PSL equivalents.  Goal
4 has been satisfied by experimenting with and analyzing assorted strategies.
Many modules of PCLS have been re-implemented several times, each time
better than the last, and some of the code is quite elegant, compared to
other implementations I've studied.  All of the stated goals have been
satisfied so far.  Note that "implementing a full Common Lisp" is not and
never has been one of the goals for PCLS.  PSL and CL are sufficiently
different than embedding one in the other will never truly win.
We are starting to discuss the design of a full Common Lisp that will
incorporate what we've learned, and that will be a publicly available
"showpiece" implementation using the best compiler and runtime system
techniques - it will however be a year or two before this is done.

>Perhaps if he spent more than five hours at something, he would
>have something to show us.  His claims of converting 1600 lines
>of code in 3 hours are totally meaningless if it doesn't work, particularly
>when he gives up on the rest after 2 hours!

Well, I spent another hour at it (in HP CL) and finally discovered that
although I had introduced a function to encapsulate the readtable changes,
it was never being called!  Even the best programming languages can't do
much about amnesia....  Once that was taken care of, 3-Lisp worked perfectly.
When I finish writing up the documentation (and maybe doing just "a little
more polishing" :-)), it will be available to anyone who wants it.

>I wonder what else is missing!

There's lots missing from PCLS, and I occasionally get requests to add
"feature X".  When I point out that the feature would require hacking or
replacing large parts of PSL, they usually decide that it's not worth
the effort (and then harass me about working harder on the new implementation,
which alas is also not part of my thesis work).

>Given all of the above, I find it difficult to take Mr. Shebs seriously.
>When he has something complete that works, learns about
>the basics of debate and argumentation, and learns a little basic
>politeness, I'll reconsider taking him seriously.

If you really don't take me seriously, then don't bother to insult me and my
postings!  Surely you're not being forced to type "F" instead of "N" to rn...

>Jeffrey M. Jacobs, CONSART Systems Inc.

							stan the tired