🚀 go-pugleaf

In <1405@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