Re: clisp - general interest in code cleanup

[<Joe...@t-...>]

Hi,

Daniel Jour wrote:

> Startup code, C string manipulation and argument parsing live together
>with memory management in src/spvw.d. This is especially concerning if the
>"topics" are intermingled.
It's always interesting when new, i.e. unbiased eyes look at old code. To
me, having arg parsing and mm in the file called spvw = Speicherverwaltung
= memory management was logical. This (set of) files contain(s) all the
low-level stuff that help create the Lisp world (of objects) that the
other files all use.

> (Emacs with projectile makes this available via C-c p s g ..
Thanks for the pointer. I should look into some of the "newer" Emacs
packages. I believe most of the commands I use already were in Emacs 18 ;-)


>Why didn't you run the concatenation as a build step?
IIRC, Bruno's Makefile did this. I didn't, because of disk space. A 1MB
file on a 80MB drive was a lot, so I preferred to work with temporary
files, i.e. only keep .d and .o on disk.

Actually, I can't remember. Perhaps for exactly the reasons mentioned
previously: comfort of working with basically one include (lispbibl.d)
and one code (e.g. spvw.d) file, each in one window of my (Emacs),
Bruno's (axe) editor or whatever people used. Emacs' incremental search
is often more effective than any combination of grep I know, even if
you add some context lines with -A or -B (sometimes grep is better,
e.g. to show all matches in tabular form).

Compare this with Linux includes, which are often annoyingly deep. I simply
view this as different design choices. Bruno preferred to e.g. cover all
variations of UNIXisms next to each other in unix.d and spvw.d, others
prefer lots of different files. Each choice makes some operations easy
and others difficult.


>Though I don't understand what you mean with the forward references?
You should first define types, then use them in function declarations;
first define low-level functions, then the callers of these. That's
the typical Pascal pyramidal ordering of program elements. For some
programs and data structures you can't preserve this hierarchical
ordering, you need forward references (IIRC, the Pascal programming
language has them too).

CLISP code is ordered like much this and I fully agree with Bruno who
once told me that it makes reviewing code easier as well as more robust.
I believe the reason is that it avoids backtracking, and the human brain
is particularly bad at backtracking, i.e. forgetting false assumptions
about behavior of code.

When you look at a function and see some call, it helps enormously to
*know* what the function does *exactly* -- because you already reviewed
it, reading from top to bottom through the file -- than to have to guess
from the name or the 10 line header description whether it may cover
this or that corner case, e.g.
 - is the second parameter allowed to be NULL,
 - is the upper bound inclusive or not,
 - what if the array is empty,
 - does it assume that lock X is held,
 - will it release lock X in case of error, etc.


>I'm not really experienced with keeping a changelog. As the CLISP
>changelog seems to be pretty detailed: How do you maintain it?
There's an Emacs mode adding nice colors while editing.

Regards,
	Jörg Höhle