[antlr-interest] Re: Preprocessors - academic question

[mzukowski at yci.com]

That's a tough problem.  You obviously can't analyze all the possible sets
of preprocessor conditions.  I don't think there is a general solution, but
try to think about what you would do if you were doing it by hand, but
analyzing the fully processed code for one specific set of preprocessor
variables.  As you change nodes, you should be able to trace it back to the
unpreprocessed code.  Things could get ugly when you have to split a
preprocessor directive in two so that the change only affects the code you
want it to, and not all code everywhere.  Managing this for multiple
configurations of preprocessor variables would be tough too.

Most people hopefully don't use the preprocessor in a brain dead way.  What
kind of transformations are you doing?  Maybe you could pick a tough example
and we could work it through.

Monty

> -----Original Message-----
> From: John Allen Green [mailto:greenj at ix.netcom.com]
> Sent: Friday, June 28, 2002 8:13 AM
> To: antlr-interest at yahoogroups.com
> Subject: RE: [antlr-interest] Re: Preprocessors - academic question
> 
> 
> Exactly.
> 
> Er, dunno what to add to that... :-)
> 
> John
> 
> 
> --On 28/06/2002 6:38 AM -0700 mzukowski at yci.com wrote:
> 
> > What is the problem you are trying to solve?  Do you need 
> to make changes
> > that propagate back into unpreprocessed code?
> > 
> > Monty
> > 
> >> -----Original Message-----
> >> From: John Allen Green [mailto:greenj at ix.netcom.com]
> >> Sent: Thursday, June 27, 2002 3:15 PM
> >> To: antlr-interest at yahoogroups.com
> >> Subject: Re: [antlr-interest] Re: Preprocessors - academic question
> >> 
> >> 
> >> 
> >> --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/ 
> > 
> > 
> >  
> > 
> > Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 
> 
> 
>  



 

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


 

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