Re: Preprocessor
On Wed, 23 May 2001 at 22:16:51 +0900, Martin Buchholz
<martin(a)xemacs.org> wrote:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes:
Hrvoje> The *huge* disadvantage of using a custom preprocessor is that in that
Hrvoje> case your code is no longer C code, which means that it cannot be
Hrvoje> analyzed with the usual C tools such as lint or cflow, debugged with
Hrvoje> GDB, etc.
Well, gdb can be taught (perhaps) about the source code through #line
directives in the generated source.
To solve the problem of printing lisp variables like bell-volume, when
C only understands bell_volume, we would have to teach gdb how to turn
lisp variable names into C variable names, but that strains the
capabilities of gdb's command language.
I've hacked gdb internals before. You could teach gdb about the
enhanced language, but then all the developers would have to used a
custom gdb.
Anyways, yes, the resulting program will be much harder to debug.
And
this preprocessor is supposed to make the developer's life easier.
Yep. All good enough reasons to shoot this proposal down. I'll go sit
back in my corner and stew some more on the module interface, then.
Somewhat ironically, I actually considered this preprocessor a step
towards an Elisp-to-C translator, using the source to be preprocessed as
the target of that translator. I'll rethink that, too.
--
Jerry James, who appreciates curmudgeons that prevent young hotheads
from unnecessarily tilting with windmills