Re: prefix for yacc/bison

From: Peter T. Breuer (ptb_at_oboe.it.uc3m.es)
Date: 07/12/05 

Date: Tue, 12 Jul 2005 08:26:39 +0200

Erik de Castro Lopo <nospam@mega-nerd.com> wrote:
> "Peter T. Breuer" wrote:
> >
> > That's because it's (a) silly,
>
> Its not silly. Its the most obvious and best way to include
> two grammars in one program.

It's a hack. Encapsulating parsers is an old trick (nowadays), best
done by bundling all the globals up into a single struct and passing the
address of that struct into all the parser internals as an extra arg,
and having them access the struct fields instead of globals.

Mind you, I suppose the namespace trick is one of the simpler strides
in that direction to take. It's really almost just like playing with
the linker renaming facilities.

> >(b) meaningless. Yacc and bison are
> > work-alikes.
>
> Actually no. The grammars that yacc accepts are a subset
> of what bison accepts.

Both can do "any grammar" since the attached actions can go play with
the parser mechanisms to their hearts content. But I grant you there
probably is some minor difference if you stick to productions alone.

> > Write code that both can parse. Don't write code that only
> > one or the other can grok.
>
> Nice idea in theory, not in practice. For instance Bison
> now has a GLR parser as well as an LALR(1) parser. Yacc
> only has the latter.

Things like that are generally words for "whatever I can do". GLR as
an acronym would indicate to me unbounded lookahead, which means
unbounded stack usage internally (I am in favour of this), but I don't
know if they mean it is top down or bottom up. The semantics would be
pretty different from classical yacc bottom-up parsing if it were
top-down. And I haven't seen any indication in the yacc code I have
looked at that it is other than a state machine plus a stack, which
means a bounded lookahead bottom-up machine.

> To the original poster, the best advice you are going to get
> is to just dump yacc and only support bison.

Well, he can fix the code generated to do as I suggested using an extra
stack pointer as an argument. And/Or he can simply add a use of "sed"
to his build stage.

Use of sed would probably be it for him.

Peter

Relevant Pages

  • Re: Generic protocol builder/parser
    ... We work with both ASCII and binary protocols. ... Have a look at yacc which seems to be a reasonable match ... BNF-style input and a parser in C as output. ... the Only grammars for the true grammar aesthete. ...
    (comp.programming)
  • Re: Flex&Bison: how to write a parser for this grammar?
    ... bison? ... it's better to rely on a parser generator than on hand-written ... a yacc parser will be simpler if the grammar is suitable so ... need for flex start conditions there as I feared there might be. ...
    (comp.programming)
  • Csup cvsmode build discussion
    ... lex and yacc files that I would like to discuss. ... I implemented the RCS parser required to operate on RCS files ... I've been compiling the parser and tokenizer with the help of bison ... Now, the base system already have flex, but the flex version in base is heavily ...
    (freebsd-hackers)
  • Re: Why LL(1) Parsers do not support left recursion?
    ... LLparser generators exist, in contrast to LRparser generators. ... no infinite recursion can occur. ... grammars that are commonly used for those languages are ambiguous. ... upon an extragrammatical disambiguation rule. ...
    (comp.compilers)
  • Re: String#to_rx ?
    ... > I don't think trying to push full parser capabilities into regex's is ... > mechanism in ruby to build grammars - and easily put actions in. ... Perl 6 doesn't define the parser as a very complex string. ...
    (comp.lang.ruby)