[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0

From: Gregory Wright
Subject: Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0
Date: 12 Aug 2002 17:49:35 -0400

Hi Vadim,

On Mon, 2002-08-12 at 17:19, Vadim V. Zhytnikov wrote:
> Gregory Wright пишет:
> > On Sat, 2002-08-10 at 11:33, Matt Kaufmann wrote:
> > 
> >>Thanks.  Will COMMON-LISP and LISP ultimately be the same package?  That is,
> >>will this form return true?
> >>
> >>(eq (find-package "LISP") (find-package "COMMON-LISP"))
> >>
> > 
> > 
> > No, this should never be so. As gcl moves toward ansi common lisp, the
> > symbols in LISP should be moved to COMMON-LISP. Anything left over
> > (i.e., in gcl's LISP but not part of the 978 symbols of ansi
> > COMMON-LISP) should be moved into a compatibility package. The package
> > LISP should go away since it is a confusing remnant of the days when the
> > language was specified by the CLtL book.
> > 
> As far as I can derive from discussion of COMMON-LISP & LISP issue
> in CLtL2 and Hyper-Spec version of the ANSI standard coexistence of
> COMMON-LISP and LISP packages is perfectly legible. In such situation
> COMMON-LISP must be certainly strictly ANSI while LISP package represent
> certain local lisp dialect so let it be our old "nearly CLtL ..." GCL.

As I understand the LISP-PACKAGE-NAME issue writeup from X3J13, the
conclusion was that the package named...

        COMMON-LISP means ANSI lisp,
        LISP was generally agreed to be CLtL,

        LISP shouldn't denote a dialect of lisp or ANSI lisp.

The reasoning in the writeup is, alas, contradictory on serveral points.
It seems say that LISP can be kept for backward compatibility (or could
be a nickname for a backward compatibility package).

I guess my point was that 'LISP' is not really what most users would
consider the LISP package -- a CLtL2 LISP package. So we call it
something else to make the difference clear and set LISP as a nickname
by default.

My motivation has been trying to get emacs ILISP to work with gcl. It
works well with all of the free lisp dialects I've tested---sbcl,
cmulisp, clisp, guile, scm---except gcl. It is just different enough to
cause trouble.

> It seems to me that ANSI tests are quite revealing with respect to
> old GCL bugs.  I also don't see how adding new ANSI features cold
> affect portability?

I think it is an excellent idea to keep running the ANSI tests to find
bugs in gcl. I just wanted to suggest that no ANSI issues delay 2.5.0,
but that after 2.5.0 is released ANSI compliance be the main goal.

Best Wishes,


Gregory Wright
Chief Technical Officer
PacketStorm Communications, Inc.
20 Meridian Road
Eatontown, New Jersey 07724

1 732 544-2434 ext. 206
1 732 544-2437 [fax]

reply via email to

[Prev in Thread] Current Thread [Next in Thread]