Re: METHOD DR

[Hans Aberg]

At 13:10 +0200 2001/06/15, Akim Demaille wrote:
>  Hans> I have myself an idea of how to make Bison support multiple
>  Hans> languages in the output parsers, namely by hooking Bison up with
>  Hans> a "formatter" language that I wrote in order to make the writing
>  Hans> of C++ files simple.
...
>Hans> In the code I use now for the "formatter", the environments are
>Hans> built directly in C++ using features like std::map, so if you
>Hans> want to hook that up with Bison and keep it C, you will end up
>Hans> with some problems. I think it will be very tricky trying to
>Hans> convert it into C code, as it is heavily OO.
>
>Anyway, up to now I am not sure it deserves such an effort :(
>
>There are not that many languages we could aim at, and having to learn
>yet another language to define the output format seems overkill to me.

A skeleton file is already a "language" which has to be learnt.

And I figure you would extract only parts you need for making a C/C++
output simple, as for a start.

>And there are languages for which you shall not use $ or @, Perl comes
>to my mind.  So even on the input language, we're doomed.

I think that Bison translates $ & @ to something else, which one puts into
the macro environments. Then, if one would at alter point be interested in
having $ $ & @ in the output, one could add some escape sequences to the
Bison.

Pretty trivial, it sound to me.

-- The internals of this formatter passes over strings with no restrictions
on what can be put into them. So one can choose suitable input and output
encodings  in order to achieve the results that one wants.

>Java is very happy with its own set of tools, so is ML, Perl now has
>very powerful LL generators and so on, Ada (Gnat) too.  And so on.

A search showed that there are Bison versions for Erlang and such. With the
approach I suggest, it would be relatively easy to produce such versions.

And competition is usually the way to bring about progress, so if Bison is
easy to localize to languages, one will get an increased input on that.

>In addition, people are departing from LR, and LL is globally better.

So in what sense is LL better: Isn't LL(1) a lot of fewer grammars than
LR(1), and produces a function call build-up?

What makes you so sure this isn't a movement right now, and later one will
switch back to LR?

>So there is no reason to try to have a supra-Bison.

I didn't suggest a super_Bison; merely an approach that might simplify
writing the C/C++ parsers it generates.

>  Let's have it be
>better for its C users, and provide C++ output.

You do whatever you want, but it is a fact the current skeleton files
already is very complicated, and that C++ has not been supported yet. In
C++, there are also many different styles that a user may prefer. Handling
that with traditional C preprocessor macros seem complicated.

>Hans> Another approach would be to work the formatter up as a separate
>Hans> language so that the environments can be built from a file,
>Hans> written by Bison. One can then merge this with a macro formatter
>Hans> file (corresponding to the current Bison skeleton files) in
>Hans> order to produce the output parser code.
>
>Really, not yet another language.

The point is that one cannot in existing languages conveniently build
environments separately and them merge them with macros. This feature
simplifies writing OO language output files.

>Hans> But if you want the code for your own experimentation and
>Hans> extracting what you may need for Bison, just let me know, I can
>Hans> send you the code I have right now whenever you want.
>
>I'd like to know what other outputs you considered.

I use it only for producing C++ output, and the way I use it is that I
build the environments directly in C++ with a parser that Bison generates.
Then I read macros from a formatter file, and write out the macros
corresponding to a C/C++ header and source file. This approach
significantly simplifies the action rules and the writing of the output,
and this is the only aspect I am myself really interested in.

>AFAIC, I consider that a key feature is the ability for users to
>define their skeleton.  This, I agree.

This is the main point I hint at, at this point: For a C/C++ output, users
should very easily be able to produce their own modifications, instead of
hoping that the Bison team makes those changes by changing the next Bison
distribution.

>But bison by itself just outputs tables.

Plus some action rules, I believe.

>  That's dead simple, and
>there is no reason to have to `tune' those tables.

Right, you do not need much.

In my approach, those tables would have their entries first put into
containers, which to the formatter is a sequence of environments. Then the
formatter has the capacity, via a suitable macro, to produce the output
table.

This makes it easy to build those tables within Bison, as it does not have
to worry about the output anymore, while on the same time giving the users
the chance of producing whatever output they want by altering the formatter
macro that controls it.

>So I don't think we need to have such a generator.

Whatever you feel happy with.

  Hans Aberg