I suggest that all comments not by the author of a program be SIGNED by
the commentor.
Maybe even comments by the author should be signed, as well as
authorship of programs.
Someone reading the source code might think that Bill Schelter wrote the
whole thing, rather than transforming it to common lisp, plus adding
neat stuff that he DID write..
RJF
Stavros Macrakis wrote:
> On Jan 23, 2008 9:15 PM, Rupert Swarbrick
> <rupert.swarbrick at lineone.net <mailto:rupert.swarbrick at lineone.net>>
> wrote:
>
> However, I decided that I really needed to understand
> Maxima's simplification routines better, so I've been slowly
> working my
> way down simp.lisp. To ensure I read and understand, I've been writing
> documentation strings for the functions as I go, along with
> reindenting
> them for readability.
>
>
> Adding documentation to the CVS tree is a good idea as long, of
> course, as it is correct.
> Can you tell the cvs diff tool to ignore space? If not, changing
> indentation makes it hard to compare versions.
> Then again, even adding end-of-line comments makes comparisons harder.
> Maybe best to stick to ;; and ;;; comments on separate lines.
>
> 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.
>
>
> Yes, there is lots of redundant code. And there are at least four
> "standard" packages of utility functions: opers/mopers (which I wrote
> the ancestor of 30+ years ago); mrgmac (Mike Genesereth); rzmac (Rich
> Zippel); strmac (? most of these aren't used anywhere and include
> dangerous ops like make-***-simp).
>
> Though in theory I like the idea of making everything consistent,
> again this will cause a lot of code change that doesn't reflect
> functionality change. If we do this, it should be in one big push on
> a very well-tested, stable version, not randomly checked in. Also, it
> should be decided by the group. Your "good taste" may not correspond
> to others' "good taste".
>
> 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.
>
>
> Let's not worry about microoptimizations like this, though they are
> tempting. Ideally, we should be able to have the compiler auto-inline
> when appropriate. (I know, this depends on things like build order.)
>
> 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!)
>
>
> The code is hard to understand in many places. This also means that it
> is hard to rewrite correctly. And again, changing code without
> changing functionality makes for distracting diffs. The interactions
> among the simplification routines can be subtle, so something that
> seems like an improvement may in fact break other things.
>
> I'd recommend you take some *specific* bugs that have been documented
> and fix them as locally as possible (i.e. don't rewrite everything).
> For example, making sure that 2/sqrt(2) simplifies to sqrt(2) without
> breaking anything else.
>
> 5) (ahah there was another question) Can anyone explain the idiom of
> writing a defun containing just a ((lambda (x) ....) nil))
>
>
> ((lambda (a b c) ...) av bv cv) == (let ((a av) (b bv) (c cv)) ...)
>
> Let was introduced into MacLisp sometime in the early 1970's, after a
> lot of Maxima code had already been written. The semantics are
> precisely the same; let has the readability advantage of putting the
> a's close to the av's.
>
> -s
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>