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

[Camm Maguire]

Greetings!

Gregory Wright <address@hidden> writes:

> 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.
> 
> 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.
> 

Is this really true?  I thought that the whole idea of keeping the
LISP alongside the COMMON-LISP was to allow both to coexist for
backward compatibility purposes?  There are a few core C functions
which have to be written in one way *or* the other, as far as I can
see, but apart from these few, it appears as if we should be able to
have both functionalities in one image.  That is not to say it is
necessarily desirable, just possible, right?


> 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?
> 

This is a good idea.  I thought of it a little differently, but
currently don't have a firm opinion.  If we could divide the ansi work
into "add-ons preserving traditional behavior" and "breaks backward
compatibility", we should feel free to add the former into gcl before
2.5.0 as time permits.  I.e. we should not delay the release because
of this, but we should not retard such work either waiting on the
release.  As for the second category, some kind of bifurcation will
obviously be necessary.  Whether we will need separate cvs trees or
can branch one code base with #defines, etc, is still unclear to me.
Could get confusing if we did the former.  Already, the idea of
backporting the fixes we have made in cvs to do another stable 2.4.x
series seems quite daunting, and an unnecessary amount of work.  I
fear that the same fate will befall one of the two cvs trees if we
split as you suggest.  But maybe there is an easier way to handle the
cvs than I am aware of.  

Take care,

> Best Wishes,
> Greg
> 
> 
> -- 
> 
> 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]
> address@hidden
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah