> At 02:58 18.05.00 -0400, Stephen Pair wrote:
> >someMethod
> >         thisCompiler ifDebug: [self printDebugInfoInTranscript].
> >         self doSomething.
>
> I've no solution for this (do you know that Java programmers are
> glad that
> their language doesn't contain C-style  #ifdef macros anymore and now you
> want to introduce the same to Smalltalk?), but

Preprocessors for C/C++ we're an afterthought in that language...and their
implementation shows it, but that doesn't say anything about their
utility...I can think of few C/C++ programs that don't use preprocessor
definitions.  I'm glad that Smalltalk doesn't have a preprocessor as well.
A better implementation is to allow some way of speaking to the compiler
directly (rather that massaging the input that it receives).

By utilizing a special variable, I had hoped to avoid extending the language
with yet another new syntax.  Being able to selectively compile debug code
without modifying the source is the main motivation (you could even handle
breakpoints in this way).

> Hm, so if you really need macros, I'd vote to do it the other way round,
>
> use
>          <primitive: 1201>
> and
>          <ifDebug: Transcript show: 'Hallo'>
> or whatever

Actually, macros are not what I'm after, but rather a way to better control
the behavior of the parser and compiler.  I think I like using <> to
indicate all compile time messaging.  It would help separate compile time
things from normal code.  It's also a familiar construct.  I think the
following would be preferable to using "thisCompiler":

	<literal: [ 1 + 1 ]>
	<ifDebug: [ Transcript show: 'Hello' ]>
	<ifDebugLevelAtLeast: 3 do: [ Transcript show: 'debug stuff' ]>
	<ifTracing: [ self showTraceOutput ]>

And these could be extended by simply adding methods to a class in the
system (perhaps Compiler, perhaps some new class).

Now, once code is sufficiently debugged, you might want to strip that stuff
out of the source, which should be fairly easy to do with a tool.  Perhaps:

	aClass removePragmas: #ifDebug:.

> in this case, I'd prefer the ##( ) syntax which is easier to read and
> already supported for Dolphin and VisualAge.  I think, there's a file-in
> for VisualWorks, done by Vassili Bykow (I'm sorry, I probably misspelled
> that name).

That's a valid point, but I think I'd prefer:

	<literal: [ 1 + 1 ]>

...simply because it eliminates one extra construct.  And, I think VW does a
similar thing with the "resource" pragma if I'm not mistaken...but I don't
think VW is as flexible as treating these things as message sends to the
compiler/parser framework.

What is a good name for the mechanism?  I've often heard these things
refered to as "pragmas"...is that an appropriate term?

I really think something like this would be very useful, particularly during
the development process...and it could also aid users of a framework who
want the ability to debug the framework (the author could embed very
meaningful debug pragmas into their code without fear of hindering
performance).  This too is commonly done with C/C++ preprocessors.

- Stephen