Documentation



> I take the Macsyma Conference records wouldn't help much either?

Mostly they are about *applications* of Macsyma.  There may be a few
about *algorithms* used in Macsyma.  I remember there was one about how
Lisp worked.  But I really doubt there is anything about, e.g. the
argument conventions of functions internal to Taylor or Limit or
anything like that.  Remember, they are the Macsyma *Users'*
Conferences, not the Macsyma *Implementors'* Conferences.

> Who at MIT handles copyright issues?  The LCS doesn't seem to know.

The copyright in theses and dissertations normally belongs to the
author, not the institution.  So if we find some useful material there,
we will have to ask the individual authors for permission.  I will be
looking over some of this stuff at the MIT Libraries and Archives
tomorrow.

> Well, as long as there is some standard we are using.  What 
> do you think would be best for the long term?

For implementation notes, we can insert comments in the code.  Let's try
to keep them concise, useful, and correct.

The implementors' interface specification of a function can go in its
docstring.  We can follow the Emacs convention of the first line of the
docstring being usable stand-alone as the most concise description, e.g.

"(risplit EXPR) => ( <real part of EXPR> . <imaginary part of EXPR> )
The workhorse function of $rectform (which see for mathematical issues).
Special representations are handled by trisplit, which calls risplit."

User documentation is another matter.

> Ah.  What do you think of making example systematic?  Would 
> that make sense?

Sure, go crazy.  It's the manual.demo file.  Some embedded comments
would be nice, probably -- but I don't know what syntax it wants for
that.

     -s