bison-patches
[Top][All Lists]
Advanced

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

Re: Bison 1.5x and flexible _input grammar_


From: Akim Demaille
Subject: Re: Bison 1.5x and flexible _input grammar_
Date: 09 Oct 2002 08:21:05 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

Hi Tim (and sorry for the duplicate, I forgot the CC...),

I'm sending this on bison-patches which is probably the most
appropriate place.  I don't want to have personal messages about
projects: it doesn't last (no public archive etc.).

| [not sure this belongs on the list, so sending direct to you]
| 
| Hi Akim,
| 
| I know that the new bison has flexible backends (both in parser
| mechanism and output language), but as far as I know it uses a
| fixed input syntax (with %-options allowing configuration of the
| backends).  Am I right in thinking this?

Yes.

| I ask because the company I work for is thinking about
| doing/commissioning a research project to convert Extended BNF syntax
| into a bison grammar; of course, if such a thing could be implemented
| in bison itself, that would be nicer (and if the project succeeds, it
| would benefit the entire open source community instead of just our
| company).

This is not new!  Your company seems to be willing to spend money on a
topic which has already been beaten to death in some places.  Bison is
definitely *old* in this regard.

| I was thinking something along the lines of
| 
|   bison --grammar-type=yacc foo.y [default]
|   bison --grammar-type=ebnf foo.y (or foo.ebnf, whatever)

I'm not sure Bison is the right place for this kind of game, and I'm
not sure we need several input grammars.  Extending the current one
seems enough to me.

| With everything being pretty much the same except that the actual
| grammar part of the input file would have a different format.
| 
| Example:
| 
| [foo.ebnf]
| 
|   ...
|   %%
|   mul_a_or_b ::= (a | b)*;
|   %%
| 

This is very cute, but you didn't answer the most difficult questions:
how do you bind user code on this?  ISTR YACC++ does support this, but
it ain't simple, as can be guessed reading comp.compilers (see in July
2002 I think: the debate about ELR).

The only place I have seen this approach with success in with AST
builders, not parsers.


| [foo.y]
| 
|   ...
|   %%
|   mul_a_or_b
|   : /*empty*/
|   | plus_a_or_b
|   ;
|   
|   plus_a_or_b
|   : a_or_b
|   | plus_a_or_b a_or_b
|   ;
| 
|   a_or_b
|   : a
|   | b
|   ;
|   %%

This is the easy case, there are dark corners :(  You should really
dive into the litterature: this topic is attractive, but reveals
itself being *really* difficult.  Well, that's my understanding.

| If such functionality does not require a total rewrite of bison
| (which it might, as sematic values would of course be harder to handle
| for the * and + groupings), it seems to me to be a better solution than
| to have an external tool to translate between ebnf and yacc.  Do you
| agree, and, more importantly, would you be willing to accept patches
| that implement such functionality?

If you can prove these patches are correct and can address what people
expect, then, *of course*!  But I'm afraid it is much more delicate
that you might think.


| The project is still in the 'would be nice, but no concrete plans'
| stage, but I would still like your feedback on the idea.




reply via email to

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