[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: Matt Kaufmann
Subject: Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0
Date: Sat, 10 Aug 2002 11:25:55 -0500 (CDT)

Thanks.  So, probably it's the case that as long as the LISP package exists, we
can rename COMMON-LISP without breaking GCL.  Do I have that right?  That
should be fine for purposes of ACL2, where we do something like this.

(let ((lisp-pkg (find-package "LISP")))
  (when lisp-pkg
    (rename-package "COMMON-LISP" "COMMON-LISP-renamed")
    (let ((old-name (package-name lisp-pkg)) ; reuse old name, nicknames
          (old-nicknames (package-nicknames lisp-pkg)))
      (rename-package "LISP"
                       (cons "COMMON-LISP" old-nicknames)))))

>> (with the goal of a clean, multi-platform build of maxima and maybe
>> acl2) ....

It would be great to know that ACL2 runs under GCL on a variety of platforms!
If I can be of any assistance in helping you test ACL2, please let me know.

Thanks --
-- Matt
   From: Gregory Wright <address@hidden>
   Cc: address@hidden, address@hidden, address@hidden
   Content-Type: text/plain
   Date: 10 Aug 2002 12:07:43 -0400

   On Sat, 2002-08-10 at 11:33, Matt Kaufmann wrote:
   > Thanks.  Will COMMON-LISP and LISP ultimately be the same package?  That 
   > 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.

   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.

   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,


   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]