[antlr-interest] Re: Preprocessors - academic question

John Allen Green greenj at ix.netcom.com
Thu Jun 27 15:15:11 PDT 2002


--On 27/06/2002 10:43 AM +0200 John Allen Green wrote:

>>> Given a preprocessor which allows branching and unrestricted code
>>> substitutions, is it impossible to work with the semantics of the
>>> preprocessing itself?
>>> 
>>> It would seem to me that since you could have code substitution 
>> doing code
>>> substitution, it would be impossible to build a parse tree of the
>>> preprocessing.


I think I've finally figured out what's been bothering me. Here's some
valid Progress code:

&GLOBAL-DEFINE XX &GLOBAL-DEFINE HI "Hello world!"
{&XX}
DISPLAY {&HI}.

Of course, C doesn't let you get away with the above nonsense. What I think
the above shows is that we can't build a complete graph of the
preprocessing without actually evaluating the preprocessing expressions and
expansions.

Here's an expression that would have to be evaluated:

&IF OPSYS = "VMS" &THEN
  &GLOBAL-DEFINE OSINCLUDE include/vms.i
&ENDIF
{{&OSINCLUDE}}

We'd have to evaluate for both true and false on OPSYS = "VMS". If we never
evaluated for true, we'd never evaluate the text in the include file, and
our graph would be incomplete.

If we have to evaluate for every possible combination of conditions, then
for some compile units we might be talking about an astronomical number of
possible states, and graphing becomes impractical.

A friend suggested that this sort of graphing problem is similar to other
problems as well, and mentioned NP Complete. I've no education for this
stuff, so I'll have to hit the books for this one.

Cheers,
John


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



More information about the antlr-interest mailing list