Common or rare Lisp ?

[Luca Pisati]

Jordan Henderson wrote:
> 
> Ingemar Hulthage <hulthage@cinenet.net> writes:
> >
> >
> > I don't understand the purpose of these discussions about whether
> > certain features of Common Lisp are worthwhile or not.  One of the
> > strongest arguments for common lisp is that it's an ANSI standardized
> > OO language. To depart from that standard is suicide for any lisp, as
> > far as I can see.
> >
> 
> I can't agree with the above more strongly.  What we need is infrastructure,
> infrastructure, infrastructure.  We need a critical mass of Lisp tools and
> high quality Lisp environments so we can start to gain momentum.  The only
> way I can see this happening is if we focus on extending CL and CLOS.
> 
> A lot of the advanced language ideas expressed here are totally valid.
> I would recommend that people set off to implementing these ideas >in CL<.
> Write a testbed VM in CL and use CL to generate VM compilers for your
> new languages, or compile to X86, or whatever.  From all reports, CL,
> despite all it's flaws, makes an excellent application development
> environment.  Language compilers are applications.  If you have an
> idea for a low level language that's needed to support our overall goals
> (whatever those might be), then get started working on that low level
> language.  I would recommend that you implement it first in CL.  If
> reflectivity is crucial, write your compiler first in CL and then port
> your compiler to be defined in terms of itself.
> 
> Such a strategy that I've outlined above is a big win from the standpoint
> of developing the kind of infrastructure needed to make a LispOS a
> reality.
> 
> > Ingemar
> >
> >
> 
> -Jordan Henderson
> jordan@neosoft.com

I agree with the general concept: use ANSI-CL and not any CL
(for sure NOT Cltl1 or Cltl2 !).

But do not think that ANSI-CL is perferction. It is not.
ANSI failed to standardize vital parts of the language
as, for instance, environments.  Please check in the ANSI
specs about it, and you would see that environments DO exist
in ANSI-CL (and it couldn't be otherwise, or you couldn't even
compile and load a lisp file), but they are absolutely undefined.

Also there are some choices which are extremely arguable (and
I say this from my experience of building large ANSI-CL based
applications), as:

*default-pathname-default* merging (which ensures your software
will fail to work any time on systems where Lisp pathnames do
not match with OS pathnames, as under Unix)

EQL specializers, which somehow break part of the perfection
of the CLOS/MOP structure, and force language implementors to
do triple back flips in order to optimize code.

flat package system, which creates, yes, namespaces, but
only defer name conflict to package conflict.

And what about being able to access compiler information
at compile time ? My compiler does type inference, so that
it can optimize my code, but I cannot access that information
so that I can optimize the way I want (again, missing
environments ...).

And what about MOP ?

So, the base is definitively ANSI-CL, but, no fear to push
the Lisp community to finalize a lot of open questions, and
no fear to force de-facto standards on system related items
as a standard syntax for Foreign Function interfaces.

Otherwise you end up in using ANSI-CL + your own layer of
encapsulation, duplicated over and over and over.

--
Luca Pisati		       Voice:	 (310) 577-0518
Nichimen Graphics	       Fax:	 (310) 577-0577
12555 W. Jefferson #285        EMail:    mailto:pisati@nichimen.com
Los Angeles, CA 90066          Web:      http://www.nichimen.com