packages, objection orientation, list of functions

(Sorry for wandering off topic Jim)

--- Richard Fateman <fateman@cs.berkeley.edu> wrote:

> While we are keeping a list of system functions,
> (an index, even) let me suggest we also start a
> list of all possible error messages and where
> they come from.

Yes, this definitely sounds like a good idea.

> Some of the messages come from the underlying
> lisp system; whether these can be caught and
> made into Maxima messages in some "system independent"
> fashion is unclear to me.  Certainly it can be done
> in ANSI CL, with error handling, but maybe not
> in everyone's favorite lisp.

I think Maxima should (at this point) assume ANSI CL.
Most (all?) of the major free lisps are moving towards
ANSI.  Supporting other cases just adds more overhead.
Of course, if someone really wants support for something
else they can do it, but they'll have to maintain it.

> I think that using packages modelled on CL packages
> would provide a possible solution; I do not particularly
> care for its utility. 

What do you find limiting about its utility?  The major
goals of such a system (as I understand it) would be 
a) provide a system where system components exist as 
distinct objects rather than throwing all definitions 
into one namespace and b) hiding "system" functions from
the user.  Of course, in lisp packaging you can break
through this barrior without too much difficulty, but the
point is it can't happen accidentally.  What features
would you look for in a package system that are incompatible
with the Lisp system?

> On the other hand, other models
> may be no better.  There is a package system
> in Mathematica that has undergone some use and perhaps
> modification.  I do not know its details, but anyone
> trying to devise one for Maxima should certainly
> look at it.

A good idea.  But here's another thought - if we don't
use lisp packages, we will have to impliment, debug, and
maintain a different solution ourselves.  I'm not saying
it isn't worth it, but before we invite the extra work
I think we should have a clear idea why the lisp packages
are insufficient, AND why the new system is enough better
to justify the effort.

> One could also look into object-oriented coding,
> given that packages are attempting to do some of
> the same partitioning of information, methods, etc.

My understanding was CLOS and packages covered
somewhat different areas, but I have never had a really
good grip on that.  I think there was a discussion on 
that in #lisp once - I'll have to track it down again. I
know you were speaking generally, but if we impliment
some object-oriented convention in Maxima at the code
level CLOS is the obvious choice barring an EXTREMELY
good reason.  (One of the main limitations of Garnet
today is that it doesn't use CLOS, and so is extra work
for anybody using it as an interface to CLOS code.)

CY


		
__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com