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

[Camm Maguire]

Greetings!  First of all, thanks you for this very helpful and
insightful note!

Gregory Wright <address@hidden> writes:

> On Sat, 2002-08-10 at 14:49, Camm Maguire wrote:
> > Greetings!
> > 
> > Gregory Wright <address@hidden> writes:
> > 
> > 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

Did you have something you wanted to finish here?  In any case, I'm ok
with renaming the current LISP package if that works for everyone.

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

Great!  Consensus!


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

Agreed!  

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

This is a very useful comment, raising an issue which I haven't fully
considered.  In any case, I wouldn't want more than one
ANSI_COMMON_LISP C macro.  In fact, at some point I'd ideally love to
find time to clean out crufty old macros.  They should only be used
for portability issues in my mind, not features.  Features can be
toggled, however, via configure, which in essence would optionally run
'make' in certain subdirectories extending the saved image, much in
the way --enable-ansi works now.  Rigorously following this pattern is
not so easy, as we already have C macros supporting readline, bfd,
gmp, etc.  I've tried not to forcibly shift everyone over the new
stuff if they still need the old, e.g. Windows and relocations.
Hopefully by release time we'll be able to thin out the options.  I
must confess, though, that this is the first software project of this
sort I've ever managed, and I really don't know what the best thing to
do is in many cases.  Your experience here is very helpful.

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

I like this in general.  I'll try to have time to dig out our old
discussion of gcl's roadmap, updating it for the progress thus far,
and making clear what we feel we must have before release.  The
portability stuff is one, but there are quite a few other mundane
tasks, like license checking, adding missing documentation, etc.
Feedback here most appreciated!

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

Indeed I suspect this is the case.  

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

OK, I'm relieved :-)

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

I agree whole-heartedly and love this new phrase!

Take care,

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

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