Re: clisp - general interest in code cleanup

>> 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.

When I read Speicherverwaltung (I'm unsure whether you know: I'm German :) ),
then what comes first to my mind is "malloc" and "free".
Thus, I'm basically expecting some sort of interface where I can request (and
free, normally) pieces of memory that satisfy some requirements (like size,
alignment) and which I can then use to create "objects" in them.
This view is probably heavily influenced by C++, though.

I also always favoured separation of "startup" code and "normal operation"
code. (When working on a OS kernel, that separation helps to get rid of the
former once the system is up)


>>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).

I always forget how limited memory once was :) While reading further through
CLISP's code I found Emacs' search to be more effective than grepping at times
when I wanted to go to the previous or next occurence, starting from the
current point.


> 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.

Searching through Linux includes can be a real pain, indeed. I'm glad to
be able to experience what it's like working with the other "extreme".


>>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).

So (regarding C) you mean forward declarations of structs and functions,
and you opt against them when possible (by keeping code that references
functions/structures "beneath" them)? That's a good approach IMO, and it
also works well with small files (albeit it's sometimes difficult to break
cyclic dependencies).
The way you describe that reminds me of "bottom up" programming (as
described by Paul Graham).


> 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.

Yes, forgetting a false assumption about a piece of code can be hard. OTOH
I found it sometimes to be helpful to not know exactly what some function
does but to first see how it's used: This made it easier to understand the
function itself.


> 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.

Reading from top to bottom through the file ... that reminds me a bit of
literate programming (I tried this only in Haskell). I guess it's a bit
like reading a book: You don't want to have to jump 100 pages ahead in
order to understand the current chapter. Structuring code like that is
IMO good, though it only works if one really starts reading from the top.

The issue is if one does not have the time to start reading from the top,
but must/want to make a change now. If you jump right into spvw.d and
start reading code, then there's a lot that you have to look up (and
eventually "backtrack", if you made a false assumption).

That's why I like "layered" approaches: You put low level code into a
separate file and create an include file that contains only what you're
supposed to be using in "higher" layers together with a extensive summary
of how these functions and structures behave and are to be used.
(Though that's not an argument for separate files ... all of this could
of course live in the same file; I think it's the "summary" that's the
critical thing which is missing for some parts of the CLISP code)

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel