Richard Fateman wrote:
> 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?
Personally I like .cl for Maxima's Common Lisp code. But Common Lisp
has a large heritage. Hundreds of programs are written in
Common Lisp. Is .cl really in use among CL programs? If not then
changing .lisp -> .cl might be misleading.
> .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.
Right now Maxima uses .mc and .mac for maxima code.
And actually in current Maxima source tree you can find
files with other extensions (even .txt) which are turned out to be
Maxima code. I think we should choose one variant.
This is certainly a large work and it must be thoroughly
planned but proposed Maxima 5.9 seems like a good
stage to do such reorganization to make clean background
for future development.
>
> .fasl conventional name for compiled version of .cl file
> perhaps .o if that is what CLISP or ... provides.
This is background Lisp dependent. Installation scripts
for particular Lisp system or binary package packager must take
care about it.
> .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...
>
Right now such documentation is in .usg files. I do not mind
changing extension to another one but .doc now is mostly
associated with MS Word files even in Unix world.
>
> 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.
>
Well, I admit this. But such situation should be treated as exceptional
case rather than general rule. And source code is always readily available
since Maxima is open source software. To an user source code should go into
another package (say maxima-src) and installed on demand.
Vadim
[ Vadim V. Zhytnikov <vvzhy@mail.ru> <vvzhy@td.lpi.ac.ru> ]