[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bison 1.50 experiences

From: Hans Aberg
Subject: Re: Bison 1.50 experiences
Date: Fri, 18 Oct 2002 23:14:58 +0200

At 13:38 -0700 2002/10/18, Paul Eggert wrote:
>> I found the file from Bison outputs to M4 useful when writing my own
>> skeleton files.
>Surely you can catch this yourself by telling Bison to invoke the
>following script instead of m4:
>#! /bin/sh
>tee /tmp/bison.m4 | m4 "$@"

You mean on a UNIX computer. :-) (I still have MacOS pre-X which does not
have UNIX.)

>From the general point of view, sure I can tweak the Bison sources to do
those things -- I already did create such a bison.m4; that's how I found
out its usefulness. :-)

But the question is if the typical Bison user that may merely want to write
a customized parser generator source will do that. Then, if there is not an
easy way to extract the file called bison.m4 above handed over to M4, then
one will either have to write extensive documentation of what macros Bison
outputs to M4, or expect of having to answer that frequently in the mail

-- I think that the M4 approach changes the picture somewhat: It is not
necessary now anymore to make a single skeleton file that contains all, as
people can treat it as just another source code file, and write their own
variations. No stranger than .y source files, really.

For example, in the C++ parser generator file I am writing, I decided to
remove all POSIX style macros, not really because POSIX does not say
anything about C++ or that I think that POSIX is irrelevant, but instead
because I figure that if one really needs a POSIX compatibility C++ parser,
then one should write special parser generator files for that. If POSIX
macros are not needed, then their presence will only pollute the C
preprocessor namespace.

-- It is too complicated to put too much into a single parser generator
file simply, so it is better to write several ones, I think.

  Hans Aberg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]