Thread overview
Question from Bison's maintainer on the D backend
Nov 18, 2018
Bastiaan Veelo
Nov 19, 2018
Manu
Nov 19, 2018
Manu
Nov 27, 2018
Carl Sturtivant
Nov 21, 2018
H. S. Teoh
November 18, 2018
Hello, Akim Demaille, the maintainer of the famed GNU Bison parser generator, reached out to me with the following (published with his accord):

====
I’m the maintainer of GNU Bison, which is a parser generator for C/C++ and Java.  A few years ago someone contributed a D backend for Bison, but at that time, the investment in Bison was low.  Now I’m spending time on it, and Richard Stallman asked me to contact the « D community » to know whether there would be interest for such a backend.

Bison is a LALR(1), LR(1), IELR(1) and GLR parser generator.  It’s based on ye olde yacc, by it features several interesting properties.

Of course the D world already features several parser generators, some being even embedded in the language and benefiting from compile time function evaluation.  So it’s very unclear to me if Bison would get some interest.

What would you think about that?
====

I wrote back that Bison is currently much more sophisticated than the present alternatives in the D community, and that we'd be interested in continued maintenance of the D backend for Bison. Further discussion revealed:

====
I would say that my first and foremost worry would be to integrate something which is not used, and not maintained.  And I am not a D programmer, so I would not be able to decide whether his work was good or not, have it evolve with Bison and releases of D.

Also, something that somewhat worries me is that the D parser was based on the Java parser, not the C++ one.
====

More thoughts and reports from the community would be helpful. If you are a current or former Bison user with the D backend, or if you have an interest in contributing reviews and patches for it,  please chime in.


Thanks,

Andrei
November 18, 2018
On Sunday, 18 November 2018 at 15:56:47 UTC, Andrei Alexandrescu wrote:
> Hello, Akim Demaille, the maintainer of the famed GNU Bison parser generator, reached out to me with the following (published with his accord):
>
> ====
> I’m the maintainer of GNU Bison, which is a parser generator for C/C++ and Java.  A few years ago someone contributed a D backend for Bison, but at that time, the investment in Bison was low.  Now I’m spending time on it, and Richard Stallman asked me to contact the « D community » to know whether there would be interest for such a backend.
>
> Bison is a LALR(1), LR(1), IELR(1) and GLR parser generator.  It’s based on ye olde yacc, by it features several interesting properties.
>
> Of course the D world already features several parser generators, some being even embedded in the language and benefiting from compile time function evaluation.  So it’s very unclear to me if Bison would get some interest.
>
> What would you think about that?
> ====
>
> I wrote back that Bison is currently much more sophisticated than the present alternatives in the D community, and that we'd be interested in continued maintenance of the D backend for Bison. Further discussion revealed:
>
> ====
> I would say that my first and foremost worry would be to integrate something which is not used, and not maintained.  And I am not a D programmer, so I would not be able to decide whether his work was good or not, have it evolve with Bison and releases of D.
>
> Also, something that somewhat worries me is that the D parser was based on the Java parser, not the C++ one.
> ====
>
> More thoughts and reports from the community would be helpful. If you are a current or former Bison user with the D backend, or if you have an interest in contributing reviews and patches for it,  please chime in.
>
>
> Thanks,
>
> Andrei

Without ever having seen a parser generated by the Bison D backend, and my last use of Bison itself being close to two decades ago, I too think that Bison’s sophistication is not yet matched by current D parser generators. We do have generators that are easier to use than Flex+Bison, which probably makes it more difficult to generate interest in (maintaining) a D backend. With the ever increasing C++ compatibility of D it would be interesting to know if and how well a parser generated by the C++ backend would work. Nevertheless I would expect that a dedicated D backend can produce nicer parsers with a nicer interface. Regarding being based on the Java backend: If the C++ backend relies on the preprocessor (I don’t remember) then that may be the reason why (as dpp did not yet exist). It would be interesting to know why being based on that backend is worrisome; What downsides does that imply?

I don’t think that I will be able to get involved in Bison (too far in development using Pegged) but parsers are fun and I hope that others have more valuable input on this matter.

Regards,
Bastiaan.
November 18, 2018
I use Bison in a D project, but since it emits C/C++, I use an
elaborate extern(C++) based solution to interact with the Bison
output.
The binding layer is hard to maintain, and I don't work on the project
much because of the friction.

I evaluated the native D parsers, but quickly switched back to Bison
because it just works, and works very well.
I was also motivated by the fact the parser also had C++ output, since
writing any project exclusively in D is a risk, and reverting to C++
is always a possibility in the event D fails.

I can say for certain, if Bison emit D output, I would use it, and get much value from it!

On Sun, Nov 18, 2018 at 8:00 AM Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> Hello, Akim Demaille, the maintainer of the famed GNU Bison parser generator, reached out to me with the following (published with his accord):
>
> ====
> I’m the maintainer of GNU Bison, which is a parser generator for C/C++
> and Java.  A few years ago someone contributed a D backend for Bison,
> but at that time, the investment in Bison was low.  Now I’m spending
> time on it, and Richard Stallman asked me to contact the « D community »
> to know whether there would be interest for such a backend.
>
> Bison is a LALR(1), LR(1), IELR(1) and GLR parser generator.  It’s based
> on ye olde yacc, by it features several interesting properties.
>
> Of course the D world already features several parser generators, some being even embedded in the language and benefiting from compile time function evaluation.  So it’s very unclear to me if Bison would get some interest.
>
> What would you think about that?
> ====
>
> I wrote back that Bison is currently much more sophisticated than the present alternatives in the D community, and that we'd be interested in continued maintenance of the D backend for Bison. Further discussion revealed:
>
> ====
> I would say that my first and foremost worry would be to integrate
> something which is not used, and not maintained.  And I am not a D
> programmer, so I would not be able to decide whether his work was good
> or not, have it evolve with Bison and releases of D.
>
> Also, something that somewhat worries me is that the D parser was based
> on the Java parser, not the C++ one.
> ====
>
> More thoughts and reports from the community would be helpful. If you are a current or former Bison user with the D backend, or if you have an interest in contributing reviews and patches for it,  please chime in.
>
>
> Thanks,
>
> Andrei

November 18, 2018
On Sun, Nov 18, 2018 at 10:41 PM Manu <turkeyman@gmail.com> wrote:
>
> On Sun, Nov 18, 2018 at 8:00 AM Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> > Hello, Akim Demaille, the maintainer of the famed GNU Bison parser generator, reached out to me with the following (published with his accord):
> >
> > ====
> > I’m the maintainer of GNU Bison, which is a parser generator for C/C++
> > and Java.  A few years ago someone contributed a D backend for Bison,
> > but at that time, the investment in Bison was low.  Now I’m spending
> > time on it, and Richard Stallman asked me to contact the « D community »
> > to know whether there would be interest for such a backend.
> >
> > Bison is a LALR(1), LR(1), IELR(1) and GLR parser generator.  It’s based
> > on ye olde yacc, by it features several interesting properties.
> >
> > Of course the D world already features several parser generators, some being even embedded in the language and benefiting from compile time function evaluation.  So it’s very unclear to me if Bison would get some interest.
> >
> > What would you think about that?
> > ====
> >
> > I wrote back that Bison is currently much more sophisticated than the present alternatives in the D community, and that we'd be interested in continued maintenance of the D backend for Bison. Further discussion revealed:
> >
> > ====
> > I would say that my first and foremost worry would be to integrate
> > something which is not used, and not maintained.  And I am not a D
> > programmer, so I would not be able to decide whether his work was good
> > or not, have it evolve with Bison and releases of D.
> >
> > Also, something that somewhat worries me is that the D parser was based
> > on the Java parser, not the C++ one.
> > ====
> >
> > More thoughts and reports from the community would be helpful. If you are a current or former Bison user with the D backend, or if you have an interest in contributing reviews and patches for it,  please chime in.
> >
> >
> > Thanks,
> >
> > Andrei
>
> I use Bison in a D project, but since it emits C/C++, I use an
> elaborate extern(C++) based solution to interact with the Bison
> output.
> The binding layer is hard to maintain, and I don't work on the project
> much because of the friction.
>
> I evaluated the native D parsers, but quickly switched back to Bison
> because it just works, and works very well.
> I was also motivated by the fact the parser also had C++ output, since
> writing any project exclusively in D is a risk, and reverting to C++
> is always a possibility in the event D fails.
>
> I can say for certain, if Bison emit D output, I would use it, and get much value from it!

That said, to your question, I have no experience with the Bison D
backend (it never occurred to me that such a thing may exist)... just
the C++ backend.
Where are builds to try out?

November 21, 2018
On Sun, Nov 18, 2018 at 10:56:47AM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
> Hello, Akim Demaille, the maintainer of the famed GNU Bison parser generator, reached out to me with the following (published with his accord):
> 
> ====
> I’m the maintainer of GNU Bison, which is a parser generator for C/C++
> and Java.  A few years ago someone contributed a D backend for Bison,
> but at that time, the investment in Bison was low.  Now I’m spending
> time on it, and Richard Stallman asked me to contact the « D community
> » to know whether there would be interest for such a backend.
[...]

Yes, I'm interested!  It has been a while since I needed to use bison, but being able to generate D code from bison would be great for my DSL projects.

The quality of the generated D code, though, is a tricky question. Ideally, it should generate an API idiomatic to D, but from what I remember of bison's generated API, it probably doesn't lend itself very well to template-heavy range-based code that typical D code would expect.


T

-- 
Some ideas are so stupid that only intellectuals could believe them. -- George Orwell
November 27, 2018
On Monday, 19 November 2018 at 06:45:59 UTC, Manu wrote:
> That said, to your question, I have no experience with the Bison D
> backend (it never occurred to me that such a thing may exist)... just
> the C++ backend.
> Where are builds to try out?

I'd like to try out the existing D backend too! Exciting news!