Re: Preprocessor

I too have thought about the idea of a Lispifying preprocessor for C, to avoid all the kludges necessitated by CPP and the broken C language. I've been tempted to make changes similar to the ones you propose. James, you have looked at other implementations that have done this, right? I believe one of the free lisps (CLISP?) does something like this. In my opinion, the disadvantages outweigh the advantages, at least for the changes you are planning. When the changes are done, no end user will see any advantage from the changes, except that build times will be a little slower. And the advantages for the developer are smaller than you might think. Mostly cosmetic. I doubt that the changes will succeed in making the module API that much more stable. With or without the changes, the stability of the module API depends on the will of the future xemacs maintainers. People often underestimate the impact of huge changes like this. There will be a ton of documentation that needs to be aligned with the new world. Will you remember to fix up the "make TAGS" target in the top-level Makefile? Will xemacs still be debuggable? Will .gdbinit keep working? Will xemacs know to use cc-mode for editing those funky .xc files? Will cc-mode understand the DEFSPECIAL foo ... as a function definition? Will func-menu? Will etags? Etc, etc. And some things will break that you cannot fix, because they're not part of xemacs. Like some developer's function cgrep { find . -name '*.[ch]' -print | xargs grep "$＠" ; } Many of these things are trivial, but for many of them, _others_ are paying the price. Everybody wants to change the world. But it's a lot harder to deal with _all_ the consequences. Now I didn't say we shouldn't have a preprocessor for C. But we better have a damn good reason. Getting rid of GCPROs seems to me a lot better reason than the "better API" reason. Curmudgeonly yours, Martin