Re: METHOD DR

[Akim Demaille]

>>>>> "Hans" == Hans Aberg <address@hidden> writes:

Hi Hans,

I'm leaving the whole content of your message for the archives.

Hans> At 16:51 +0200 2001/06/14, Akim Demaille wrote: If you find that
Hans> the algorithms you use are in some sense better than the LALR of
Hans> Bison, I think myself it would be interesting to have them a
Hans> part of GNU.
>>  This has to be evaluated.

Hans> Right. But for backwards compatibility, the new algorithms would
Hans> either be a Bison option or an entirely new independent version
Hans> of Bison -- and the latter option may require a new name.

Very much agreed.

I know nothing about DR, never heard about it before.  Is it `upward
compatible' with LALR(1)?  What are the differences?  Performances?
Error recovery?  More grammars are supported?  What _useful_ grammar
is DR and not LALR(1)?

Hans> "CJ" is evidently quite keen of doing this stuff, so it seems
Hans> important to give him (or her) the chance if doing it. So the
Hans> practical evaluation will happen earliest a few months down the
Hans> road, when there is stable version available.

As I said, I have students in charge of handling the remaining
issues.  Bison 1.29 should be released with a couple of months, sooner
if everything goes fine.

Hans> As for the algorithm itself, I found some talks and papers by
Hans> Internet searching for "Jose Fortes discriminating reverse", but
Hans> not anyhing that looked like being an objective evaluation
Hans> relative other algorithms. So it is difficult to say, from the
Hans> general point of view, why this algorithm should be preferred
Hans> over others.

Hans> -- To "CJ", it is perhaps a "Spanish connection"; I do not know.

  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. The basic idea is that one can produce a
  Hans> series of environments which merge with macros in a formatter
  Hans> file which the formatter picks together to output files. Bison
  Hans> would then in this approach produce the environments, and the
  Hans> formatter file the macros for language specific output.

>>  You could expose this solution to my students.  I'll introduce
>> them to the list within a week.

Hans> I think you said there will be no C++ support in Bison 1.29, and
Hans> from your time line, it sounds as though this will happen
Hans> (earliest) in a few months time.

There is no contradiction in there :)  There will be none, but while
they (we) wrap 1.29, they can start working on Bison NG.

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

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.

In addition, people are departing from LR, and LL is globally better.
So there is no reason to try to have a supra-Bison.  Let's have it be
better for its C users, and provide C++ output.

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.


Hans> And then there are some design issues of this macro languages
Hans> (like what features to put into it and how to enable them),
Hans> which may not be of so much concern to you if you only want to
Hans> use it for writing Bison parsers: These are features that are
Hans> needed for my OOPL, like the ability to produce arbitrarily deep
Hans> nested localities, which depend on a TeX like expanded
Hans> definition \edef within macro definitions.

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.

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

But bison by itself just outputs tables.  That's dead simple, and
there is no reason to have to `tune' those tables.

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