Re: implementing #include etc without pre-preprocessing

ok@cs.rmit.edu.au (Richard A. O'Keefe)
21 Mar 1997 10:27:00 -0500

          From comp.compilers

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)
| List of all articles for this month |

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.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.