Re: pretty-printing with yacc and lex

Scott Stanchfield <scooter@mccabe.com>
22 Mar 1996 21:34:15 -0500

          From comp.compilers

Related articles
Source for compiler using yacc/lex wanted platon!fauzan@uunet.uu.net (1996-03-05)
Re: Source for compiler using yacc/lex wanted pjj@cs.man.ac.uk (1996-03-08)
Re: Source for compiler using yacc/lex wanted theedge@sun11.rbg.informatik.th-darmstadt.de (1996-03-22)
Re: pretty-printing with yacc and lex scooter@mccabe.com (Scott Stanchfield) (1996-03-22)
Re: pretty-printing with yacc and lex macrakis@osf.org (1996-03-27)
| List of all articles for this month |

From: Scott Stanchfield <scooter@mccabe.com>
Newsgroups: comp.compilers
Date: 22 Mar 1996 21:34:15 -0500
Organization: McCabe & Associates
References: 96-03-042 96-03-058 96-03-145
Keywords: C, comment

As long as people use _reasonable_ pre-processor definitions, there
should be no problem pretty-printing code (or doing some other analysis
such as that done by our toolset.)


The problem is that some people use the pre-processor to "re-write"
the C language. They add extra "keywords" like THEN (having a null
definition). They can define things like:


#define foreachI {int i;
#define init(x) for(i=x;
#define lessthan(y) i<y;
#define nextplus i++;
#define dothis ) {
#define end_dothis }


foreachI init(1) lessthan(10) nextplus
dothis
<statements>
end_dothis


(I realize this is silly input, but it, or something like it if I
messed up, could be used to basically create a new language out of C.
Some people might think this is more readable. No comment from me...)


Anyway, the above could cause severe problems for something analyzing
the C source w/o pre-processing it.


On the flip side, if we _assume_ that _most_ C programmers will embrace
the language and not do evil (ok, so I commented on it...) things like
the above, a simple processor could be written to pretty-print the code.
Just make sure you add a caveat that "some preprocessor definitions may
cause undesirable effects when pretty-printing. Make sure you look at
your code after pretty-printing it."


In other words, I tend to agree with our moderator, but for different
reasons. (I also agree that Lex and Yacc have some problems...)


-- Scott




>Our moderator writes:
>>[I actually think that lex and yacc are lousy tools to use for a pretty
>>printer, because they throw too much information away.
>...
>
>If you have some actions in the lex (e.g. doing things with newlines
>and comments) as well as in the yacc (e.g. spotting the ends of
>control structures that don't have an explicit terminating keyword),
>and as long as you are careful about lookahead, then surely you should
>be able to do just about anything you want?
>[Not really, for the reasons outlined in the previous message on this topic.
>C has a two-level grammar, and the techniques you use to parse it don't lend
>themselves to recreating the source code. -John]


felix gaertner wrote:
> I have used lex and yacc (better: flex and bison) to build a multi
> purpose prettyprinter and in most cases it works fine. Actually, the
> project that I did was to build a prettyprinter generator that would
> build a prettyprinter from a formal specification of how a given
> language should be prettyprinted. I haven't experimented with a lot
> of languages (only Pascal and C), but the results come out nicely
> (even with preprocessor commands).


--
Scott Stanchfield McCabe & Associates -- Columbia, Maryland
[The Bourne shell was originally written using a large set of preprocessor
macros which made the source look a lot like Algol68. I can't imagine that
any C prettyprinter would have been able to do anything useful with it. -John]
--


Post a followup to this message

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