Re: Thoughts on the simplification of CLISP

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

Hi,

Blake McBride wrote:

>As a person with more than 25 years C experience, approaching the .d files
>is an unnecessary barrier.  When a C programmer wants to look at CLISP, the
>first thing he sees is this wacko, foreign .d stuff.   I'd say:

>Use as many macros as needed, but don't use .d files and processors.
Python and Java have annotations which are truly a means to preprocess the
code before it goes through the regular, old fashioned compiler. Why not
do the same with C? Because nobody else does it?

What exactly is the problem with the .d files?  Is it a matter of tool support,
e.g. your favourite editor not able to perform syntax highlighting?

Would it be better if // was used to introduce line comments?
Then rename the files to .c (still preprocessing them)?

CLISP is not the only project that puts the preprocessor to fancy uses.

>It's like having to learn a new language.
I fail to see the problem. As you have 25 years of experience with C,
I'd guess you have learned a gazillion many languages since then
(e.g. Makefile, configure, whatever).

Isn't the problem, fundamentally, not the suffix .c or .d but rather
the unusual job of programming a stack machine, i.e. program a little
Forth, while within the syntax of C? My feeling has always been that
what makes writing C code in CLISP difficult is to get the pushSTACK()
and pops right, and never spill a value.

Like with Forth, what becomes important to document in comments is the
state of the stack (esp. ToS) before and after execution of a function.

(other things are: understand the different stack frames and learn
 when to use which one, understand the dozen different array formats and
how to dispatch them correctly based on a discrimination tree, etc.)

IOW, the problem is not surface rather than content.

Regards,
	Jörg Höhle