--- Robert Dodier wrote:
> About Lisp versions --
>
> > It's slowly being untangled. GCL is moving toward ANSI,
> > and most of the others are there. So the effort required
> > should be less and less over time.
>
> Apparently ANSI compliance isn't strong enough to
> ensure that Lisp versions are compatible from Maxima's
> point of view. It's the stuff around the edges that
> matters -- how does Lisp interact with the operating
> system, how does it treat files, how does it handle
> packages, etc.
I guess so - have we run into such things lately? I thought most of
our recent problems were with meeting SBCL's strict requirements for
correct lisp code. There is of course the gcl describe problem.
> > If Maxima can run on two totally different systems and
> > get the same mathematical result, it is a reassurance
> > that there are no subtle problems with one of the lisps.
>
> Getting the same result on two Lisps is very weak evidence.
> There is a much stronger, simpler, and less aggravating
> debugging method, which is to figure out what is the
> right answer, and then see if Maxima produces it.
> Indeed, that's how the Maxima test suite works.
Right, when the answer can be figured out in a reasonable amount of
time by hand. Part of the purpose of CASs is to push mathematics into
places where this isn't true.
> > I do agree that it would be nice if the time spent
> > on these issues were to go into mathematical/feature work.
>
> I agree 100% on this point.
I think Dr. Fateman asked a good question though - is all time spent on
lisp issues time lost on mathematical issues? I don't know - my gut
says probably not. Plus, in at least some cases, when something is
rewritten to not cause trouble on different lisps it also gets
rewritten more cleanly and with better documentation. Maxima needs
quite a bit of internal tuning even not considering multiple lisp
compiler issues.
> > But I think the best way to ensure Maxima is here
> > for the long haul is to make it as portable as possible.
>
> Essentially we are trading an ongoing time sink
> (supporting multiple Lisps) for the one-time effort
> which would be required if we bet on one project, in the
> unlikely event that project went belly up.
Right. I'm not sure which is the best tradeoff. Personally I prefer
to retain flexibility at all times, but that's just me. Ultimately
it's up to the people doing the work :-).
> What Maxima needs for the long haul is not portability,
> but first and foremost, to lose the strangeness which
> permeates it like the blue stuff in blue cheese,
Vote - best analogy of the day :-).
> and secondarily, to gain the features which other math package
> have; a more powerful symbolic integration routine would
> get us a lot of new users. Supporting multiple Lisps is
> neutral wrt the second goal, and actively working against
> the first.
I dunno - I think working on multiple lisps is actually an incentive to
get rid of the strangeness (depending on whether you mean user level
strangeness or source code strangeness) because it makes that goal
easier.
Ultimately I guess it's not really an issue to worry about too much. I
think with this next release we will begin focusing much more closely
on mathematical bugs (ala bug database) so it might start to get better
from a mathematical vs. lisp standpoint.
CY
__________________________________
Do you Yahoo!?
Yahoo! Personals - Better first dates. More second dates.
http://personals.yahoo.com