Related articles |
---|
implementing #include etc without pre-preprocessing sfrederi@asc.corp.mot.com (Sudhakar Frederick) (1997-03-16) |
Re: implementing #include etc without pre-preprocessing thetick@scruz.net (Scott Stanchfield) (1997-03-18) |
Re: implementing #include etc without pre-preprocessing bothner@cygnus.com (1997-03-21) |
Re: implementing #include etc without pre-preprocessing ftit07bv85@pop.anti.wanadoo.spam.fr (1997-03-21) |
Re: implementing #include etc without pre-preprocessing ok@cs.rmit.edu.au (1997-03-21) |
Re: implementing #include etc without pre-preprocessing sethml@ugcs.caltech.edu (1997-03-22) |
From: | ok@cs.rmit.edu.au (Richard A. O'Keefe) |
Newsgroups: | comp.compilers |
Date: | 21 Mar 1997 10:27:00 -0500 |
Organization: | Comp Sci, RMIT University, Melbourne, Australia. |
References: | 97-03-090 97-03-107 |
Keywords: | lex, parse, C |
Sudhakar Frederick <sfrederi@asc.corp.mot.com> wrote
> Is it practical to implement "conditional compilation" C-style
> constructs similar to #include, #define #ifdef etc. as part of the
> parsing rather than through a pre-processor.
If I recall correctly, SAIL did this. There was a paper about it.
The Burroughs PL/I compiler supported the PL/I "preprocessor"
facilities, and they later showed up in their DMSAlgol compiler (or
you could have them in the normal Burroughs Algol compiler if you
chose to install that feature). Both Burroughs and SAIL used a
coroutine for this. Note that these `preprocessors' allowed loops and
procedures as well as if-then-else. For the SAIL preprocessor it was
_necessary_ to integrate preprocessing with parsing because the SAIL
preprocessor can test the semantic properties of identifiers.
I've worked on a total of two macro assemblers (one for an imaginary
machine and one for a real one). Both of them integrated
`preprocessing' with the normal pass 1.
Once you sort out clearly _why_ you want to integrate preprocessing
and parsing you'll have a better idea of what to do:
- is it because creating and co-ordinating processes is impossible,
difficult, or expensive in the environment where the compiler must run?
- is it because the language you are using does not permit the use of
coroutines or threads within an address space? (Even in C you can do
a lot with QuickThreads or PThreads, and they're standard in Ada and
Java.)
- is it in order to be confident of tying error messages to the right
locations?
- is it so that the preprocessor can access semantic attributes of
identifiers?
Note that Common Lisp's equivalent, #+<features> <form> and
#-<features> <form> is handled directly by the reader (parser); the
omitted <form>s still have to be well-formed (syntax) but are not
further processed (semantics). And of course Common Lisp macros are
extremely powerful. Why not just use Lisp as your input language?
I further note that the approach of conditionally skipping things but
still requiring those things to be well formed is used in SGML. (Not
_by_ SGML itself, but people can set up conditional forms in SGML DTDs
and then do conditional processing in a separate program.)
--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.