thisCompiler special variable

Stephen Pair spair at advantive.com
Thu May 18 14:16:35 UTC 2000


Hmmm...maybe I wasn't clear in describing what I meant.  "thisCompiler" is
not a global check at all, but a special variable that is a reference to the
compiler that is actively compiling the code (whatever kind of compiler that
may be).  Any messages sent to "thisCompiler" in a method would be sent at
compile time.  Those messages would not necessarily be compiled into the
bytecodes of the resulting method.  You are free to send any message to
"thisCompiler"...just like any other object.  The node representing a
message send to "thisCompiler" never appears in the bytecodes of the
compiled method (neither is the result).

The message #ifDebug: would take the block node (generated from the block it
was passed) and only insert it into the compiled method if some debug flag
were set (which could be a flag in the class, not a global).

The message #valueNow:, could generate an immediate #doIt from it's block
node (generating an error if there were references to any temp or inst vars)
and place a literal reference to the result directly into the compiled
method.

If there was an assignment of the result of a message sent to
"thisCompiler", or if the result was used in some other statement, the value
would simply be a nil VariableNode (or a block node in the case of #ifDebug:
when in debug mode, or the immediate result in the #valueNow: case).

I just really hate commenting and uncommenting debug code...what I want is a
simple way to put debug code in a method that remains there such that the
source doesn't need to be modified just because I'm toggling debug mode.
Also, when not in debug mode, I don't want so much as test for debug mode in
the compiled code.

- Stephen

> -----Original Message-----
> From: Roel Wuyts [mailto:rwuyts at vub.ac.be]
> Sent: Thursday, May 18, 2000 5:32 AM
> To: squeak at cs.uiuc.edu
> Subject: Re: thisCompiler special variable
>
>
> Instead of using these kind of global checks in the code, it is probably
> better in this case to just override the #compilerClass method on
> the class
> side. By default this is set to Compiler, but you could override it to
> return DebugCompiler (or whatever) instead. Maybe you could
> override this to
> check in that specific place to see whether debugging is enabled or not
> (which would eliminate the checks throughout the code).
>
> BTW: The Colored Syntax should have been done that way too, I think ...
>
> > I've always wanted a way of specifying compile time directives in method
> > source.  I just had a thought that it might be nice to expose a
> new special
> > variable called "thisCompiler" (or maybe thisParser?).
> >
> > Then we could write code like:
> >
> > someMethod
> >
> >  thisCompiler ifDebug: [
> >   self printDebugInfoInTranscript.
> >  ].
> >  self doSomething.
> >
> > - or -
> >
> > someMethod
> >
> >  ^thisCompiler valueNow: [
> >   IdentityDictionary new
> >    at: 'US' put: 'United States';
> >    at: 'UK' put: 'United Kingdom';
> >    yourself
> >  ].
> >
> > - or even -
> >
> > someMethod
> >
> >  thisCompiler primitive: 'primname' module: 'modulename'.
> >  self primitiveFailed.
> >
> > ---
> >
> > In the #ifDebug: case you could set or reset a compiler flag
> for debugging,
> > then re-compile all senders of #ifDebug: to yield compiled methods with
> > either the debug code embedded, or ignored.  The second case is an
> > alternative to special syntax that other dialects introduce
> (dolphin allows
> > ##() to denote evaluation at compile time).  Also, (but less
> importantly) it
> > could be used to eliminate the special syntax for primitive
> declarations.
> >
> > I haven't really thought through the idea, but at first glance
> it seems like
> > it would be very useful.  I might take a stab at it if people
> think it's a
> > good idea.  Thoughts?
> >
> > - Stephen
> >
>
>
> --
> Roel Wuyts                    Programming Technology Lab
> rwuyts at vub.ac.be              Vrije Universiteit Brussel
> http://prog.vub.ac.be/~rwuyts
> Webmaster of European Smalltalk User Group: www.esug.org





More information about the Squeak-dev mailing list