On 1/10/2011 9:25 PM, Robert Dodier wrote:
> On 1/10/11, Mark H Weaver<mhw at netris.org> wrote:
>
>> + ;; Modified by Mark H Weaver<mhw at netris.org> in January 2011 to add
>> + ;; support for MCOND expressions containing more than one non-T
>> + ;; condition, i.e. elseif, which was added after this code was
>> + ;; originally written by RJF. The format of MCOND expressions is
>> + ;; documented above the definition of dim-mcond in displa.lisp.
> I'm sorry to say it, but this is a mess.
I think it is fine.
> I'm all for comments in the code, but please, in the name
> of all that is good, just stick to what's technically relevant.
In general one may not know what is technically relevant. Sometimes people
take out code because they simply don't understand that it has to be there.
Certainly this has happened numerous times in the last 12 months.
If you want to make a distinction between technically relevant (goes in
the source)
and non-technically relevant, (in CVS only), you are probably assuming
more skill than most people have. I think that comments like the
above are important to avoid some subtle breakage
and the code would be really hard to repair, unless one were online with
CVS, and willing to delve into it.
The fact remains that when I see certain hands are responsible for certain
pieces of code, I use that as a clue as to where the bug may be.
I'm not sure that CVS would help in exactly the case of the
subtle breakage in tex of mcond that was introduced by Raymond Toy in 2005
in nparse.lisp, and updated by Robert Dodier in 2006.
(the bug being introducing elseif to the parser and not fixing all the
other places that
needed fixing.)
It might be good to point out in a comment in the code
for nparse that changes to the language may need to be reflected in
other places that may not be obvious. The obvious ones are
evaluation, simplification, display. Tex is maybe not so obvious.
maybe string() and fortran(). But the fortran() command seems to be
quite weak, and can't handle if-then-else much less if-then-elseif-..
Whether it is relevant that tex() was written before 2005 or not
would not appear in the CVS for nparse, if indeed anyone would think
to look there. Or maybe it doesn't matter how the bug was produced if
Mark Weaver fixes it?
> Commentary like the stuff shown above is best left to
> the CVS log.
>
> Maybe in some rare cases it is necessary to let the outside
> world intrude in form of names and dates and historical
> commentary. But for crying out loud, consider what a swamp,
> what a mess Maxima would be if we had decades of such
> cruft cluttering up the code.
Look at the first couple of pages of nparse.
There are pieces of source that can, in my opinion, be cut out, and have,
such as specialized
assembly code that ran only on machines no longer in existence, like
the PDP-10 (KA model). or on software that no longer runs, like
ITS, the Incompatible Timesharing System.
But eliminating code forever, or removing comments is bad policy, I think.
Sometimes I leave code around
(defun foo()...)
;; old foo, for comparison
#+ignore
(defun foo() ...)
This has the excellent property that the old version of foo can be
loaded into
lisp / Maxima to replace the new one with meta-control-x.
I find that replacing lines one at a time is much less convenient.
> Interesting parts of Maxima have
> been touched by dozens of hands over many years -- do we
> really need to recapitulate the whole freaking Old Testament
> in order to show what the code does?
Sometimes it is not a bad idea. Especially when the "new" comments
turn out to be wrong, based on a misunderstanding of the Old Testament
code, and having those comments (and even code) around can help.
Yes one can revert code with CVS, too.
> It's too ugly to
> contemplate.
The programmers of today are not immune from making mistakes.
The test-suite hardly tests everything.
The fact that some change is recorded in the CVS apparently
provides some people with more comfort than for me..
RJF