[GD-General] RE: Preprocessors

[Brian H. <bri...@py...>]

> Or simply that they intend for you to use existing 
> preprocessors.

Fair enough, but then you have source code that won't recompile between
different build systems because of a different choice of preprocessors.
Imagine the hell we'd be in today if, for example, things like #if,
#define, #error, etc. were not standardized in the C language.

> There is little to stop you from using the C 
> preprocessor as a front-end for most languages out there.

Quite true.  Unfortunately others may opt to use no preprocessor, a
hacked preprocessor, or they'll use Perl and custom syntax, which ends
up causing problems.

In addition, for interpreted languages it may not be feasible to run a
preprocessor every time you want to load up and run some script.

Anyway, my point wasn't necessarily that this is insurmountable, since
it obviously is not, it's just that in my experience language designers
get really defensive about this topic.  There's this weird unwillingness
to admit that commenting out large blocks of code is actually useful.

Typically someone will tell you to use:

if ( 0 ) { put dead code here };

Unfortunately that dead code still needs to compile, so it doesn't help
when you have some weird parsing error and you're trying to find it.
For languages like Eiffel and Lua, which lack comment blocks, trying to
hunt down some parse error can be irritating.  Java at least still
retains /* */, although you can't nest them.

Of course, I'm sure some Emacs geek will suggest writing some custom
elisp that prepends each line in a selection with the appropriate line
comment, be it '--', '//', ';', or '#'.

Hell, for all I know Emacs already has a M-x comment-region-with-#
command =)

Brian