--- Nikodemus Siivola wrote:
> On Tue, 21 Jun 2005, C Y wrote:
>
> > (defpackage :maxima-declarations
> > (defpackage :maxima-destructuring-let
> > (defpackage :maxima-compatibility-macros1
> > (defpackage :maxima-compatibility-macros
> > (defpackage :maxima-prerequisites
>
> ...ad nauseam..
>
> Commenting purely as a style and sanity issue, this sounds like a
> rather bad idea. Packages aren't C++ or Java classes, which is what
> this list brings to mind. Neither are they build units, which is
> what these also sound like -- I would expect these to be filenames,
> not packages.
I suppose in the strict normal use of lisp packages this is not
standard practice, but that's not my primary reason for doing this. I
want to compartmentalize as much of the Maxima code base as possible,
so that the scope of functions is more easily understood. As a result
it should be much easier to predict the impact of new changes and
features both inside and outside the package.
I'm not quite sure I'm seeing the problem - from my point of view I
WANT Maxima broken down into fine pieces, because those are simpler to
understand and work with. Perhaps some of the categories can be
improved, but from my point of view having a lot of them is a very
desirable thing.
> Having multiple packages for a project the size of maxima is most
> likely a good idea, but unless those package delimit functional
> units things make no sense.
Well, the basis for those package names comes from the maxima.system
groupings of modules, which in turn load specific files. Some can
probably be consolidated, and over time the structure can be shifted to
more intuitive arrangements. The thing to do at this point is to get
things, as much as possible, into self contained units with clearly
mapped dependancies. That is a much stronger position to work from.
> I would expect more then a dozen or so packages to be a mistake
> unless you can really justify each and every one of them: if you
> can write a short description of the functionality provided by a
> package that makes sense to other people as well _and_ in relation
> to other packages, then it probably is a package. If not, then
> something is off the track.
OK, fair enough, but my knowledge of Maxima is insufficient to make
such arguments for lower level functionality. That's one of the goals
of this project, to make code relationships clear. I'll add another
criteria to the above test which comes from the other direction - if
any package cannot be well defined as to its task and methods used to
impliment that task (being "the" Maxima package won't count), then it
needs to be compartmentalized until it CAN be well defined. At the end
of this we want as transparent a code base as can be managed - Maxima
suffers quite a bit from not being an easy read for new programmers.
Personally I expect it will take quite a bit more than a dozen packages
to achieve the latter, given the complexity of the system. We already
have three or four even with the current monolithic structure. Plus
packages defined in share will also bump the count.
> > (defpackage :maxima-TeX
> > (defpackage :maxima-plotting
>
> To contrast and compare -- these sound perfectly sensible to me.
> "TeX output routines." "Plotting tools."
I would argue the following are also clear, or can be broken down
further to be made clear:
maxima-numerical - numerical routines
maxima-simplification - simplification code
maxima-server - server code
maxima-language-compiler - Maxima language to lisp translation
maxima-reader - functions to read in code
maxima-display - functions to display results
maxima-documentation - describe, other inline documentation
functionality
maxima-integration - integration routines
maxima-trigonometry - sin, cos, tan, etc. etc. etc.
maxima-matrix-algebra - routines to handle matricies
maxima-limits - code for handling limits
maxima-solve - solve routines
maxima-debugging - special debugging commands and environments
maxima-sets - code for handling set operations
maxima-fortran - fortran routines
maxima-ordinary-differential-equations - ODE code
Others I would need to look at more carefully, but this is already over
a dozen. I'm not afraid of a large package list - in fact I think it
is a necessary and natural reflection of the sheer complexity of
Maxima. But that's just me.
Cheers, and thanks for the input.
CY
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com