On Thu, 24 Jan 2008 12:03:57 -0500
"Stavros Macrakis" <macrakis at alum.mit.edu> wrote:
> 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.
I don't think you can tell CVS to ignore space, sadly. My thought was
that at the moment simp.lisp (and no doubt other files) are rather
hairy, so it might be worth making exactly one "doc+reformat" commit,
which was possibly huge, but didn't contain _any_ code changes
whatsoever. Then, although it would look a bit awful in CVS, it'd still
be safe as it physically couldn't introduce regressions.
Indeed, one could separate the doc and reformat steps themselves.
I really would argue for reformatting though: code like this:
(defmfun simplifya (x y)
(cond ((atom x) (cond ((and (eq x '$%pi) $numer) %pi-val) (t x)))
((not $simp) x)
...
is rather difficult to parse by eye and contains a lot of functionality
on each line, the second being a problem with diff-based version
control systems.
>
> 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".
Yikes! That's quite impressive! But seriously, I think there are two
possibly conflicting priorities here. One is absolute: there should be
no regressions. However, if we can, I?think we'd gain a vast amount by
refactoring and combining this sort of code: the whole tree would
slowly get easier to read and, more importantly, understand enough to
fix bugs in.
I completely agree about the good taste comment. Although I think there
are some things that are objective: when writing new code avoid gotos
maybe :) (Yes, I know that the stuff I'm moaning about was probably
written in the '70s when e.g. loop didn't exist)
>
> 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.)
(I think I may have answered this somewhere else, but what I meant was
that you could elide a lot of code by writing a macro or two here and
there for this sort of stuff, making the whole lot easier to read.
Anyway, that's low priority I agree).
>
> 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.
I sort of agree, and sort of don't. (Sorry!) Firstly, I agree that
there's absolutely no point in changing code just for the fun of it.
However, I'm not so sure that every change needs to "add
functionality". The mere existence of ancient bugs in the sf tracker
suggests that some of them are fundamentally hard to fix with the
current architecture, which is understood by maybe only a couple of
people (you and Richard Fateman maybe?).
Simplifying the lot of it might not be as much of a waste of time and
as dangerous and pointless an exercise as you suggest?
>
> 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
Ah! I wondered if that was it! Thanks
Rupert