3-Lisp

Stanley Shebs

unread,

Jul 8, 1986, 11:08:14 AM7/8/86

to

There has been some interest in my recent but rather cryptic mention of
the Lisp dialect "3-Lisp".

3-Lisp was first defined in Brian Smith's thesis from MIT in 1982 ("Reflection
and Semantics in a Procedural Language", MIT LCS TR-272). It's about 500
pages of pretty heavy going, and the Maclisp implementation in the appendix
is too full of bugs to be really useful. There are papers by Smith in the
84 POPL in Salt Lake City, and in the 84 Lisp conference, where he and Jim
desRivieres show an implementation method. Xerox PARC Intelligent Systems
Lab report ISL-1 is the reference manual (it's titled the "Interim 3-LISP
Reference Manual, and is also coauthored with Jim desRivieres). I believe
there are later manuals from either PARC or CSLI, which is where Smith is at
these days.

I have an implementation of 3-Lisp that used to work in PSL, but then
I translated it to Common Lisp, and as of yet have not gotten the
necessary readtable hacking to work yet (3-Lisp requires massive and tricky
changes). I hope to have it finished sometime this summer (if I can find
the time!). The implementation has been specially hacked to spill its
guts while running, since reflection is rather a mysterious process, and
one can't really understand it without seeing it in action. However, it
is ridiculously slow. A good compiler for 3-Lisp would be very difficult,
since reflection requires that one be able to produce, manipulate, and
re-install the full state of the virtual machine at any time.

stan

Jeffrey Jacobs

unread,

Jul 10, 1986, 12:26:28 PM7/10/86

to

In <1...@utah-orion.UUCP>, Stan Sheb writes:

>I have an implementation of 3-Lisp that used to work in PSL, but then
>I translated it to Common Lisp, and as of yet have not gotten the
>necessary readtable hacking to work yet

So much for the wonderful portability of Common Lisp!

To add another story about the wonders of porting to Common
Lisp from a Local User's Group meeting of one of the Lisp Machine
companies, "I ported a large program from Zeta-Lisp to Common
Lisp. After I had it almost working, I decided I'd had enough. I
wouldn't use the Common Lisp version".

The person telling this story shall remain nameless, but definitely
knows what s/he is doing...

For those who have been unable to understand some of my points
about Common Lisp and how it SHOULD have been done, see the
EuLisp/ISO draft standards!

-Jeffrey M. Jacobs, CONSART Systems Inc.
P.O. Box 3016, Manhattan Beach, CA
CIS:75076,2603
BIX:jeffjacobs

sh...@utah-orion.uucp

unread,

Jul 11, 1986, 11:16:41 AM7/11/86

to

In article <14...@well.UUCP> jja...@well.UUCP (Jeffrey Jacobs) writes:
>
>In <1...@utah-orion.UUCP>, Stan Sheb writes:
>
>>I have an implementation of 3-Lisp that used to work in PSL, but then
>>I translated it to Common Lisp, and as of yet have not gotten the
>>necessary readtable hacking to work yet
>
>So much for the wonderful portability of Common Lisp!

I was afraid somebody might jump on this, and tried to phrase vaguely
to leave some doubt, but obviously that didn't help. OK, I'll explain.
3-Lisp requires a special readtable that redefines things like #\(, #\`,
#\$, etc. The 3-Lisp implementation code in CL also likes a couple
of extra definitions, although they're not required. During the process
of firing up a 3-Lisp, you need to flip back and forth between these
two readtables several times. Fine, just create the two readtables
and rebind them! Unfortunately, the two implementations I worked with
were PCLS and an early version of a commercial Common Lisp. PCLS is
embedded in PSL, which stores macro character definitions on property
lists, and this is the behavior that PCLS inherits. This is OK since
PCLS is a subset, but it means that rebinding of *readtable* is out.
There is another way to go that involves the copy-readtable function,
but PCLS didn't have that either, and the commercial CL's version
didn't work. So I hacked out one for PCLS but it's unfinished, since
I'm now working on a full reader instead of borrowing PSL's.
To put all this in perspective - I spent about 3 hours converting the
1600 lines of the 3-Lisp implementation from PSL to CL, and about
2 hours fiddling with the readtable stuff in PCLS and the other CL.
3-Lisp is not real high on my list of priorities...

>To add another story about the wonders of porting to Common
>Lisp from a Local User's Group meeting of one of the Lisp Machine
>companies, "I ported a large program from Zeta-Lisp to Common
>Lisp. After I had it almost working, I decided I'd had enough. I
>wouldn't use the Common Lisp version".

People writing Zetalisp programs have a habit of using everything
in the language they can find, and as a result find they can't port
their program from Zetalisp to *any* other dialect. Blame Symbolics,
not Common Lisp.

>For those who have been unable to understand some of my points
>about Common Lisp and how it SHOULD have been done, see the
>EuLisp/ISO draft standards!

Eulisp proposes some fairly radical things, some of which (like
explicit environment objects) have not really been tested in a
production environment. If you read Julian Padget et al's paper
that will appear at the Lisp conference, you will find out about
a great many holes that need plugging. Of Eulisp's three levels
of functionality, the top is essentially Common Lisp, so a "full"
Eulisp implementation will be indistinguishable from a Common Lisp.
If CL is the worst thing that's happened to Lisp, Eulisp won't be
any better...

>-Jeffrey M. Jacobs, CONSART Systems Inc.

stan shebs

r...@h.cs.cmu.edu.uucp

unread,

Jul 11, 1986, 9:30:58 PM7/11/86

to

>>I have an implementation of 3-Lisp that used to work in PSL, but then
>>I translated it to Common Lisp, and as of yet have not gotten the
>>necessary readtable hacking to work yet
>
>So much for the wonderful portability of Common Lisp!

Of course, most people will realize that translating from one language to
another has nothing at all to do with the portability of the target
language.

----------------------------------------------------------------------
Rick Busdiecker
The Robotics Institute ...!seismo!h.cs.cmu.edu!rfb (UUCP)
Carnegie-Mellon University r...@h.cs.cmu.edu (ARPA)
Pittsburgh, PA 15213
(412) 268-7654
----------------------------------------------------------------------

jja...@well.uucp

unread,

Jul 12, 1986, 12:24:47 PM7/12/86

to

In my original msg, portability should have been COMPATABILITY. mea culpa

-Jeff Jacobs, CONSART Systems Inc., Manhattan Beach, CA

mar...@kuling.uucp

unread,

Jul 15, 1986, 10:31:02 PM7/15/86

to

In article <14...@well.UUCP> jja...@well.UUCP (Jeffrey Jacobs) writes:
>

>In <1...@utah-orion.UUCP>, Stan Sheb writes:
>
>>I have an implementation of 3-Lisp that used to work in PSL, but then
>>I translated it to Common Lisp, and as of yet have not gotten the
>>necessary readtable hacking to work yet
>
>So much for the wonderful portability of Common Lisp!

Common Lisp is not supposed to compatible with all other existing lisps.
CL is portable between different CL implementations. You have the
same problems porting from lisp X to CL as from lisp X to any other
lisp Y.

>
>To add another story about the wonders of porting to Common
>Lisp from a Local User's Group meeting of one of the Lisp Machine
>companies, "I ported a large program from Zeta-Lisp to Common
>Lisp. After I had it almost working, I decided I'd had enough. I
>wouldn't use the Common Lisp version".
>
>The person telling this story shall remain nameless, but definitely
>knows what s/he is doing...
>

I have ported a large program from FranzLisp to Common Lisp. No
problems at all. Got some bugs fixed in the original at the same
time, so in the new version works better. And it runs easy on the
Lambda (in CL-mode) so CL is indeed portable.

>...

>
>-Jeffrey M. Jacobs, CONSART Systems Inc.
>P.O. Box 3016, Manhattan Beach, CA
>CIS:75076,2603
>BIX:jeffjacobs

--
Per-Erik Martin, Computing Science Dep., Uppsala University, Sweden
UUCP: mar...@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!martin)

jja...@well.uucp

unread,

Jul 18, 1986, 12:12:50 PM7/18/86

to

In <14...@well.UUCP>, Stan Shebs writes:

>>For those who have been unable to understand some of my points
>>about Common Lisp and how it SHOULD have been done, see the
>>EuLisp/ISO draft standards!

>>-Jeffrey M. Jacobs, CONSART Systems Inc.

>Eulisp proposes some fairly radical things, some of which (like

>explicit environment objects) have not really been tested in a
>production environment. If you read Julian Padget et al's paper
>that will appear at the Lisp conference, you will find out about
>a great many holes that need plugging. Of Eulisp's three levels
>of functionality, the top is essentially Common Lisp, so a "full"
>Eulisp implementation will be indistinguishable from a Common Lisp.
>If CL is the worst thing that's happened to Lisp, Eulisp won't be
>any better...

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 it's publication. I will simply state that
the paper describes a MUCH better **approach** to philosophy and
design than that of Common LISP.

"a great many holes that need plugging" is grossly misleading. It
implies that there are major inconsistencies and/or a lack of solutions
to problems. This is simply not the case, in either Padget's paper or
the proposed ISO/EuLisp standard. There are open questions, which
is why the ISO/EuLisp is still a draft, but these are not "holes".

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.

When discussing the "top level" of EuLisp, level 2 there is an apparent
desire to be _compatible_ with Common LISP, NOT to be a "full" CL.
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.

This is a very open issue, and, given the inconsistencies
and problems in Common LISP, I strongly doubt that they would
commit themselve to hanging themselves by a foolish committment
to a standard still in need of major revision.

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.

He defends Common LISP with a nearly religious zeal, using
a style and technique that remind me most of a post-pubescent
"student of Objectivism. His preferred means of 'rebuttal'
consist foremost of ad-hominem, and"straw men" arguments.
The balance consists mostly of stamping things as "bogus" or
"a crock". Misstatement fills out his repertoire. Technical content
is either totally lacking or impossible to find among the derogatory
adjectives.

In the same message, he goes on to explain why he couldn't
port 3-LISP from PSL to PCLS. The basis of his excuse is that
PCLS is "a subset". There are no accepted subsets of Common
LISP, as Mr. Shebs himself has previously stated. So PCLS is simply
incomplete and therefore "broken".

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

In my first article, I pointed out the difficulties and time required
to do a "full" implementation of CL; PCLS is not only not full, it
doesn't even cover some of the basics (if there are any in CL).

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!

>but PCLS didn't have that either...

I wonder what else is missing!

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.

Jeffrey M. Jacobs, CONSART Systems Inc.

P.O. Box 3016, Manhattan Beach, CA 90266
CIS:75076,2603
BIX:jeffjacobs

Stanley Shebs

unread,

Jul 19, 1986, 3:27:51 PM7/19/86

to

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

In article <14...@well.UUCP> jja...@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

Rob MacLachlan

unread,

Jul 21, 1986, 3:49:37 AM7/21/86

to

The current discussion of Common Lisp and Eulisp seems to be missing the
most fundamental aspects of the disagreement due to an obsession with
superficial technical issues. The missing dimensions are the political and
the psychological.

It is evident from Mr. Jacobs messages that the Eulisp design effort has its
true basis in anal retentive neurosis. Consider the frequent use of sexual
metaphor and innuendo in his messages:

>From: jjacobs@well
>Subject: Re: 3-Lisp
>Date: Fri, 18-Jul-86 12:12:50 EDT
>Reply-To: jja...@well.UUCP (Jeffrey Jacobs)
>Keywords: Lisp, 3-Lisp, purity, reflection
>
Consider the keyword "purity" in his subject header. He has barely begun
his ejacluations, yet he has already revealed his latent pederasty for the
world to see.

>For those who have been unable to understand some of my points
>about Common Lisp and how it SHOULD have been done, see the
>EuLisp/ISO draft standards!
>

[In another message, referring to Mr Shebs.]

>He is either unwilling or unable to understand and address the issues.
>

As is usually the case with borderline psychotics, he assumes that anyone
who disagreees with him has misunderstood him. Unfortunately for him, we
understand him all too well.

>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 it's publication.
>

This obsession with secrecy would normally be considered an indication of
paranoia, but in this case I believe that is caused by a fear of inadequacy
(here quite justified).

> I will simply state that
>the paper describes a MUCH better **approach** to philosophy
>

He loses touch with reality, forgetting that we are discussing a practical
programming language rather than some misguided attempt to make a
philosophically pure language.

>"a great many holes that need plugging" is grossly misleading. It
>implies that there are major inconsistencies and/or a lack of solutions
>to problems. This is simply not the case, in either Padget's paper or
>the proposed ISO/EuLisp standard. There are open questions, which
>is why the ISO/EuLisp is still a draft, but these are not "holes".
>

See how he is made uncomfortable by the phrase "plugging holes." His fears
of sexual inadequacy lead him to attempt to redefine the terms by
equivocating.

>The standard points 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.
>

Thus we see that a subconscious sexual prudery underlies the entire language
design; Mr. Jacobs is not the only unstable person involved. The themes of
"purity" and "cleanliness" provide strong confirmation. A major
subconscious theme of the anal retentive personality is acute uneasiness
with bodily secretions, either literal or symbolic. Cleanliess thus becomes
an obsession in their diseased minds.

>Mr. Shebs seems to have a basic inability to distinguish between
>forests, trees and shrubs.
>

Recall that "beating around the bush" is a euphimism for adultry.

>He defends Common LISP with a nearly religious zeal, using
>a style and technique that remind me most of a post-pubescent
>"student of Objectivism."
>

Yes, but the ambience of Eulisp is decidely pre-pubescent. Not only do the
designers lack the experience of the Common Lisp designers, they are
physically incapable of this experience due to their comittment to obsolete
hardware. The problem is that in Lisp design (as in other things),
theoretical knowledge is no substitute for experience. Their attempt to
construct a standard out of youthful enthusiasm and thin air is doomed to
failure. The so-called "Eulisp standard" is merely a case of premature
ejaculation. I freely admit the shortcomings of the current Common Lisp
definintion, but it is pure wishful thinking to suppose that a full
specification for a language having the power of Common Lisp can be
constructed in only a year or two.

>His preferred means of 'rebuttal'
>consist foremost of ad-hominem, and"straw men" arguments.
>

May I point out that you are the innovator in the character asassination
department. The second half of the rather long message to which I am
replying is entirely devoted to attacking Mr Shebs. On occasion, he did
lower himself near you level, but on the whole has been an exemplar of
reasonableness compared to you. If a Common Lisp implementor made an attack
on your person, you would notice it, as it would resemble this message.

>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.
>

Rest assured that no serious language designer will take you seriously. Of
course if you had any constructive criticism to offer, you would be welcome
to join Mr. Shebs in the Common Lisp community.

>Jeffrey M. Jacobs, CONSART Systems Inc.
>P.O. Box 3016, Manhattan Beach, CA 90266
>CIS:75076,2603
>BIX:jeffjacobs
>

Rob MacLachlan, Carnegie Mellon University.
Programmer, Spice Lisp project:
"Making the free world safe for symbolic programming..."

Rob MacLachlan

unread,

Jul 25, 1986, 4:21:47 AM7/25/86

to

The current discussion of Common Lisp and Eulisp seems to be missing the
most fundamental aspects of the disagreement due to an obsession with
superficial technical issues. The missing dimensions are the political and
the psychological.

It is evident from Mr. Jacobs messages that the Eulisp design effort has its
true basis in anal retentive neurosis. Consider the frequent use of sexual
metaphor and innuendo in his messages:

>From: jjacobs@well
>Subject: Re: 3-Lisp
>Date: Fri, 18-Jul-86 12:12:50 EDT
>Reply-To: jja...@well.UUCP (Jeffrey Jacobs)
>Keywords: Lisp, 3-Lisp, purity, reflection
>
Consider the keyword "purity" in his subject header. He has barely begun
his ejacluations, yet he has already revealed his latent pederasty for the
world to see.

>For those who have been unable to understand some of my points

>about Common Lisp and how it SHOULD have been done, see the
>EuLisp/ISO draft standards!
>

[In another message, referring to Mr Shebs.]

>He is either unwilling or unable to understand and address the issues.
>

As is usually the case with borderline psychotics, he assumes that anyone
who disagreees with him has misunderstood him. Unfortunately for him, we
understand him all too well.

>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 it's publication.
>

This obsession with secrecy would normally be considered an indication of
paranoia, but in this case I believe that is caused by a fear of inadequacy
(here quite justified).

> I will simply state that

>the paper describes a MUCH better **approach** to philosophy
>

He loses touch with reality, forgetting that we are discussing a practical
programming language rather than some misguided attempt to make a
philosophically pure language.

>"a great many holes that need plugging" is grossly misleading. It

>implies that there are major inconsistencies and/or a lack of solutions
>to problems. This is simply not the case, in either Padget's paper or
>the proposed ISO/EuLisp standard. There are open questions, which
>is why the ISO/EuLisp is still a draft, but these are not "holes".
>

See how he is made uncomfortable by the phrase "plugging holes." His fears
of sexual inadequacy lead him to attempt to redefine the terms by
equivocating.

>The standard points 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.
>

Thus we see that a subconscious sexual prudery underlies the entire language
design; Mr. Jacobs is not the only unstable person involved. The themes of
"purity" and "cleanliness" provide strong confirmation. A major
subconscious theme of the anal retentive personality is acute uneasiness
with bodily secretions, either literal or symbolic. Cleanliess thus becomes
an obsession in their diseased minds.

>Mr. Shebs seems to have a basic inability to distinguish between
>forests, trees and shrubs.
>

Recall that "beating around the bush" is a euphimism for adultry.

>He defends Common LISP with a nearly religious zeal, using

>a style and technique that remind me most of a post-pubescent
>"student of Objectivism."
>

Yes, but the ambience of Eulisp is decidely pre-pubescent. Not only do the
designers lack the experience of the Common Lisp designers, they are
physically incapable of this experience due to their comittment to obsolete
hardware. The problem is that in Lisp design (as in other things),
theoretical knowledge is no substitute for experience. Their attempt to
construct a standard out of youthful enthusiasm and thin air is doomed to
failure. The so-called "Eulisp standard" is merely a case of premature
ejaculation. I freely admit the shortcomings of the current Common Lisp
definintion, but it is pure wishful thinking to suppose that a full
specification for a language having the power of Common Lisp can be
constructed in only a year or two.

>His preferred means of 'rebuttal'

>consist foremost of ad-hominem, and"straw men" arguments.
>

May I point out that you are the innovator in the character asassination
department. The second half of the rather long message to which I am
replying is entirely devoted to attacking Mr Shebs. On occasion, he did
lower himself near you level, but on the whole has been an exemplar of
reasonableness compared to you. If a Common Lisp implementor made an attack
on your person, you would notice it, as it would resemble this message.

>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.
>

Rest assured that no serious language designer will take you seriously. Of
course if you had any constructive criticism to offer, you would be welcome
to join Mr. Shebs in the Common Lisp community.

>Jeffrey M. Jacobs, CONSART Systems Inc.

>P.O. Box 3016, Manhattan Beach, CA 90266
>CIS:75076,2603
>BIX:jeffjacobs
>

Rob MacLachlan, Carnegie Mellon University.

Rob MacLachlan

unread,

Jul 25, 1986, 4:34:00 AM7/25/86