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

[Gregory Wright]

On Sat, 2002-08-10 at 14:49, Camm Maguire wrote:
> 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?
> 

It's certainly possible---perhaps I spoke too soon that LISP should go
away. However, it might be a good idea to rename it so that people who
use it know what they're getting into, i.e., not ANSI CL, not even
CLtL2, but something much closers to CLtL1. Perhaps LISP-GCL? (We could
compell the treatment of LISP-GCL as LISP as a start-up option.)

I guess I favor the approach
> 
> > 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.  
> 

I absolutely agree that ANSI add-ons preserving the traditional behavior
should be allowed into gcl whenever time permits. And that the release
should not be delayed.

Here's my thinking:

        1. GCL's main advantage is that it runs on lots of platforms.
           And it pretty zippy :-)

        2. GCL's principal 'customers'---maxima and acl2---are now
           running on CMUCL and Clisp, which are more ansi-ish than
           gcl at the moment.

We seem to make our efforts most useful to the community if we work on
ansi compatibility while preserving the wide range of platforms.

        3. Version control by #ifdef is a nightmare.

The problem is that it takes incredible care and discipline to make it
work. It could be done---you allow yourself just one kind of
conditional, #ifdef GCL_ANSI ... #elif GCL_TRAD .. #else ... #endif, so
you really have two different codebases living in the same tree. It is
essential to avoid debugging interactions between the two. No software
project has time for that sort of thing.

        4. Instead of asking, how do we get gcl to support ansi, we
           should ask what essential features would an ANSI gcl need to 
           keep the 'customer's' existing code running?

Here's a scenario: the work to get GCL to build on all the debian
platforms wraps up. GCL builds maxima and ACL2 on all platforms. Tag
this as 2.5.0_release_candidate. Fix the bugs and then release. At the
release, branch the cvs. The 2.5.0 branch only gets bugfixes. The main
branch is developed with the goal of releasing a mostly much ANSI 3.0
that builds on all platforms. Perhaps we could allow a runtime option to
turn on traditional feature (like gcc's -traditional). But no guarantees
are made with respect to traditional behavior.

Who knows? Maybe the programs out there that seem to depend on gcl's
behavior are simply working around it's idiosyncrasies?

Yes, bugfix branches tend to wither and die, but that's what they should
do as most users update to the more current versions of the software. We
shouldn't think of touching 2.4.x unless to fix a catastrophic bug. It's
what is it and 2.5.0 will be better.

I'm certainly trying to encourage us all to look at what we can possibly
avoid doing. Our company's software team is about the same size as
gcl's. We have to be pretty ruthless in deciding what really needs to be
done. Ars longa, vita brevis!

Best Wishes,
Greg

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

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