Vadim V. Zhytnikov wrote:
>
<snip>
> And some proposals about infrastructure.
>
> 1) Right now Maxima uses files with so many various extensions
> - .dm .dem .dm1 .dm2 .dmt .lsp .lisp .mc .mac - too many!
> It is good idea to standardize this better
> and reduce the number of file extensions to, say,
> .mac .lisp .usg .mac .dem.
There are a few suffixes that make sense though I don't know what
the ones above mean, entirely. Some of them seem to come from
shortening 3 or 4 letter suffixes to 2 for purposes of storing with
weak file systems.
Here is what comes to my mind
.cl for a file that is in common lisp. Thus .lsp, .lisp, .l
could be changed to .cl . Advantages: common usage, I think
and only 2 letters. Does anyone else use this?
.mc (is that in use already?) for a file that is in
the "macsyma" language. e.g. foo(x):=x+1
Since the demo files are also in this language, we could
still use it.
.fasl conventional name for compiled version of .cl file
perhaps .o if that is what CLISP or ... provides.
.doc maybe more of these variations... documentation of some
sort.
There may be some more, but I can imagine a situation
in which we have
foo.mc source code foo(x):=x+1
foo.cl result of translating (by the TRANSLATE command)
of foo.mc into common lisp
foo.fasl result of compiling into machine code foo.cl
foo.doc the documentation e.g. "foo" takes one argument...
There might also be other files, perhaps...
foo.info or foo.index meta-data about foo, generated by the compiler
or automatic processing of foo.doc??
fooaux.c C code to make foo run faster
fooaux.o compiled fooaux
fooaux.sl shared library?
foodemo.mc "basic" demonstration of the foo package
foodemo1.mc more advanced ....
There are many other parts of a project that I do not
understand, but that are made by allegro common lisp
on windows. including
system.dll
system.lpr
system.exe
system.bil
...........
Note that programs initially written in common lisp would
not have a foo.mc version.
>
> 2) The directory structure isn't very logical to me as well. Contributed
> packages now go into share, share1, share2, sharem, tensor, sym ...
> This ought to be reorganized somehow. For example, one
> directory share with subdirectories - one subdirectory for each
> contributed package or particular application area.
The reason there is share, share1, ... is, I think, that on the
PDP-10 ITS system on which Macsyma was first written in 1968, there
was a limit to the number of files in a directory, and furthermore,
directories were flat. Not hierarchical. Thus when share got
nearly full, another directory, share1 was started up. I think that
the "subject" directory structure could be taken from (for example)
Mathematica. While someone is looking at this, it might also
be reasonable to totally remove the file-name handling of Macsyma,
and just use common lisp's file name search-path, library-directory
etc. The Macsyma system's version was a synthesis of several
now dead conventions (ITS-PDP6/10, Multics, Lisp Machine).
>
> 3) Contributed packages should not be installed as source code (.mac .lisp)
> but compiled during installation process and finally installed as .o or
> .fas
> (background lisp dependent).
sometimes the .mac code will not translate/compile correctly into
machine code. The .mac or .mc files should be available, and sometimes
it may be necessary to load them.
>
> Vadim
>
> --
>
> [ Vadim V. Zhytnikov <vvzhy@mail.ru> <vvzhy@td.lpi.ac.ru> ]
>
>
>
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>