Fwd: clisp - general interest in code cleanup

[Daniel J. <dan...@gm...>]

(Resend to list, sorry for the duplication)

> Congratulations, too, for obtaining a GSOC!

Thank you very much!

> Speaking about lispbibl.d, I'm not sure it's too big, in absolute terms.
> I've learned that the "best" file size very much depends on how we use
> a file, i.e. the tools we use to manipulate it.

Definitely. I'm not so much concerned about the actual size (lines of
code, space on disk), but rather the amount of unrelated "topics" that are
put together. Example: 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.

If the only "use" of the code is when we compile the final executable, then
having all in one (or some) huge files is not so much an issue (though one
looses the ability to have functions / types / macros with the same name,
in case that's needed). But if you only want to "use" a small part of the
code, e.g. in order to test that part, that gets pretty difficult.

> However, editors are still an order of magnitude better at handling single
> files than at working with multiple, related files. How would you specify
> a search in only include files, excluding code files, e.g. record.d?

I don't think so. Not even talking about what "complex" IDEs can do, one can
always fall back to "the right tool for the job", in this case (for example)
GNU find and grep. (Emacs with projectile makes this available via C-c p s
g ..
which I read as "command project(ile) search (via) grep". There are also
ways to do semantic searches like finding callers, macro expansion points
etc,
but the simple text search has been enough for me ever since.)

To search only in include files, one would only grep in these.
Include files (normally) should have a different filename extension than
implementation files.

Consider this (contrived example):
Suppose you'd like to change the readtable related code to
not (only) work with simple vectors but also with some other (fancy) data
structure. For that you want to find all uses of simple_vector_p in those
parts of the code.

If "topics" are in different files, then one can narrow down searches based
on that, which is a huge win IMO.

> If you look closely, you'll still find comments like "ARRBIBL for
ARRAY.D".
> Lispbibl.d back then was a concatenation of those more specific include
> files. BIBL means 'Bibliothek', i.e. library. We found out that, due to
> memory fragmentation issues, it was more reliable to compile all C files
> using the one giant include file than the individual pieces.
> That's no more an issue.

That must have been tough times :) I've always been working on machines with
(compared to that) plentiful memory available, so that I never had to worry
about not having enough memory to safely run a compiler.

Why didn't you run the concatenation as a build step?


> Last but not least, like it or not, trying to create a proper hierarchy of
> tiny ordered includes costs a lot of effort and time. Unsurprisingly, all
> languages have something to use forward references. I don't know if it's
> worth the effort to change that.

That's true: "Where do I put that?" together with "How do I name that?" are
often surprisingly difficult to answer. Though I don't understand what you
mean with the forward references?

Best,
Daniel