[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: [Maxima] GCL

From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] Re: [Maxima] GCL
Date: Sat, 15 Dec 2001 13:24:06 +0300

Camm Maguire wrote:

> OK, I've added you to the list of developers on savannah.  How about I
> create a task there for the new glibc testing of both the static link
> and the patch I sent you, and assign this to you?


> > I have some quite good experience with other Lisp dialect which is _very_
> > different from CL. I've started learning CL specific just two months ago
> > so at present I'm not so good as CL compliance expert. On the other
> > hand it seems to me that you should be cautious in making GCL
> > Common List compliant. Adding to CL features which are missing
> > in GCL is always good but there are other points where GCL works
> > but works not as expected by CL standard. Consider for example
> > this renown problem with APPLY. In CL standard (as far as I understand)
> > the construction
> >   (APPLY '(LAMBDA (U) ...) '(..))
> > is not valid and this is so in clisp and cmucl. But it works on GCL and
> > I do not know what shall we do this it? If we make this construction
> > forbidden in GCL then immediately Maxima will stop work with it.
> >
> Agreed that we should not break maxima at all costs!  But how does
> maxima run then on clisp?

Take a look at Maxima source code - it contains lots of feature
conditional expressions which are different for gcl an other lisps.
So if we change some important GCL default behavior then
we have to change these conditionals accordingly but we even
don't know exactly how many places we have to fix.
Surely this can be done but it is not so simple.
Ok, even if we managed to change everything correctly.
But imagine someone downloads this new fixed Maxima
code and tries to use it with old GCL. He will be bitterly
disappointed. On the other hand better CL compliance is
certainly desirable. So, I venture to suggest the following
strategy. Let's default GCL behavior remains untouched
but stricter CL compliance is enabled by some switch.
Standard or CL-compliant mode of operation must be
properly reflected in *features*. This allows us to
change Maxima code gradually without breaking
it and maybe later default GCL operation mode may
be altered to CL-compiant one.



[ Vadim V. Zhytnikov  <address@hidden>  <address@hidden> ]

reply via email to

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