🚀 go-pugleaf

In article <1405@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes:
>
>In  <137@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