On 1/23/08, Rupert Swarbrick <rupert.swarbrick at lineone.net> wrote:
> Firstly I need to apologise to Robert Dodier, whose email I forgot to
> reply to: and then it was a couple of days ago.
Hi Rupert, no need for apologies. Things happen when people have time for them.
> 1) When I finally reach the bottom, would there be interest in
> uploading the docced file to cvs? I'm being really careful not to
> add/change code, so the only change to the sexps is a string at the
> start of each defun. Thus although it would be an enormous patch/change
> (think every line of code), there would actually be no change to the
> program, just the addition of docs!
Doc strings and comments sound like a good idea.
I'm pretty sure reformatting code is not.
Reformatting obscures the history of code and makes it harder to
see what substantial changes there have been.
> 2) There are lots of smallish utility functions in simp.lisp, in
> particular predicates like mplusp and the like. As a general comment, I
> think it might be nice to group up, say, predicates in a file of their
> own for reuse - I'm sure we'd find the same code with different names
> in different parts of the tree.
That sounds good ...
> 3) Some of this code involves lots of copy-paste - in particular the
> predicates like ratnump and mplusp, which just check (caar x) - I think
> this stuff would be quite amenable to "macroization", which would mean
> other tests on the caar could be performed trivially.
I dunno. The presence of macros makes debugging harder,
and there is a lot of debugging to be done.
I doubt if the greater speed outweighs the debugging problem plus
whatever effort has to be invested in recoding stuff.
> 4) Goto! Aargh! I never realised _how_ incredibly difficult it is to
> understand code with gotos - for example uses them heavily. Although I
> understand the code is working currently, I think it's worth going
> through this sort of thing and tidying it - after all, if I found a bug
> somewhere in the middle of simp.lisp: in plusin, say, I'd just groan
> and try to ignore it: the code's just so complicated that it's
> incredibly hard to keep in one's head at once (unless this is just me
> being rubbish!)
Recoding stuff for clarity has to be carried out with great care.
I don't know if it's worth the trouble to rework low-level stuff.
I think a bigger payoff would come from stepping back and
considering the simplification system as a whole.
Maxima's simplification stuff has three substantial limitiations:
it is not easy to extend with new rules, it is difficult to retract
existing rules, and it is extremely difficult to know what are the
rules implemented by the existing Lisp code. Making progress
on these problems requires understanding the simplification
system, but the meaning of specific (FOO (GO FOO)) constructs
doesn't really matter.
> 5) (ahah there was another question) Can anyone explain the idiom of
> writing a defun containing just a ((lambda (x) ....) nil)) as in
> eqtest? Is it just a way of doing let for ancient lisp interpreters
> that didn't have it?
Yes, I'm pretty sure it's a LET-like construct.
Thanks a lot for your interest in Maxima!
Robert Dodier