gcl-devel
[Top][All Lists]
Advanced

[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: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0
Date: Tue, 13 Aug 2002 00:19:41 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.0.0) Gecko/20020526

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.


But this brings up a good point---the moves toward ansi-fication are in
conflict with getting the basic bugs out of gcl and reliable cross
platform builds.
>


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?



Which leads to a proposal: sometime soon, perhaps just after 2.5.0 is
released, we branch the cvs, with the branch being 2.5.x maintenance
(with the goal of a clean, multi-platform build of maxima and maybe
acl2) and a development branch headed for ansi compliance. The
development branch is allowed to break backward compatibility with 2.5.x
and earlier.

The development branch could still support special features or
compatibility modes but it would not be a _requirement_.

What do people think?

Best Wishes,
Greg





--
     Vadim V. Zhytnikov

      <address@hidden>
     <address@hidden>
     <address@hidden>
    <address@hidden>









reply via email to

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