Re: Thoughts on the simplification of CLISP

> * Blake McBride <[email protected]> [2017-01-01 11:19:41 -0600]:
>
> I think step 1 is as follows.  Get rid of the .d files!  Start with .c
> files.  Use as many macros as needed, but don't use .d files and
> processors.  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.  It's
> like having to learn a new language.  I'd say:
>
> 1.  Run it through all of the preprocessors to convert all of the .d files
> to .c files
>
> 2.  With macros, clean up the .c files so that they are more reasonable.

Easier said than done.
I mean, I would love to see that happen (and I have argued for that for
years), but it is harder than it seems at the first glance.

CLISP has several pre-processors, and, while converting "# " comments is
trivial and inserting "{}" for "var" marker is no longer necessary,
"gctrigger" is different.

When a function is marked "maygc" in foo.d (i.e., it can trigger GC),
the foo.c will contain code to invalidate all data:

--8<---------------cut here---------------start------------->8---
maygc void foo (int x, object a, float y, object b) {
  ...
}
--8<---------------cut here---------------end--------------->8---

turns into

--8<---------------cut here---------------start------------->8---
maygc void foo (int x, object a, float y, object b) {
  GCTRIGGER2(a,b);
  ...
}
--8<---------------cut here---------------end--------------->8---

Do we really want to make the programmer write GCTRIGGERx(...) instead
of maygc?
It's not just the number of characters to type.
It's having to list `object` arguments _twice_.
This redundancy is, IMO, a strong argument in favor of a pre-processor.

However, the question is more of http://www.cygwin.com/acronyms/#SHTDI,
compounded by this trajectory:

* Obviously, we cannot give Bob (who just volunteered to rid us of the
  pre-processors) write access to the repo - he doesn't know what he is
  doing, he is likely to mess up things and leave them broken &c.

* We ask Bob to prove that he is actually committed to CLISP - by doing
  some minor work, which will also ensure that he understands the code
  base and will not make trivial mistakes.

* Now that he proved himself, we might actually give him free hand - but
  Bob now has more interesting CLISP stuff in mind, he is no longer
  excited by the perspective of hand-editing 100+ *.d files.

I do not mean to discourage you though.
We welcome your contributions.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net
http://mideasttruth.com http://thereligionofpeace.com http://no2bds.org
Don't be afraid of happiness.  It does not exist.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel