
GNU Bison 3.3 released - jrepinc
http://savannah.gnu.org/forum/forum.php?forum_id=9357
======
stabbles
"There are also many smaller improvements, including a fix for a bug which is
at least 31 years old."

~~~
benj111
Its weird that web pages can succumb to link rot so quickly, apps succumb to
bit rot almost as quickly, but a bug will live on.

In a thousand years time will archeologists study us through the bugs left
behind in Linux 1300.05 and windows (30)95? Do you think there will still be
jobs for Cobol programmers?

~~~
perlgeek
> but a bug will live on.

Sometimes, yes. But it has also happened often to me that an old bug I was
trying to fix was simply gone, either because the error mode has gone away, or
the feature that the bug related to has been removed.

~~~
msla
> But it has also happened often to me that an old bug I was trying to fix was
> simply gone, either because the error mode has gone away, or the feature
> that the bug related to has been removed.

And this is why groups like the OpenBSD team and the Linux kernel team are so
eager to remove support for old hardware. Removing support for the 80386
cleaned up code which no longer had to have special cases to handle opcodes
and features the 80386 doesn't have but later x86 processors do.

------
jimktrains2
I wish it were easier to have more target languages. (And that there were more
target languages.)

I know the docs say that additions are welcome, but I'm still in my infancy of
working out how to :)

Congrats though! I love it when these tried-and-true tools continue to perform
and improve!

------
jonathankoren
I always kind of wonder what people use lex and yacc for. 20 years ago I made
something to pretty print random C structs, but I have no idea what people do
with these tools. Historically, these have been billed as "compiler
compilers", and while that's certainly a use case, it never struck me as a
very popular use case.

~~~
derefr
The main advantage, to me, is that the input of Yacc is a (mostly) self-
contained, (mostly) declarative representation of the grammar to be parsed.
This format is portable between projects.

You can, for example, take Postgres’s SQL syntax parsing “engine” out of
Postgres and use it in your own project, because it’s not actually an
“engine”, but rather just a Yacc grammar.

~~~
wwright
How often are yacc/lex grammars actually portable? Truly portable too — usable
in different threading contexts, for example.

You say they are declarative. My experience is admittedly very limited, but I
would call them anything _but_ declarative. There are declarative elements,
but the actual payload of your code is very, very often imperative. (A lot of
this is shaped by the API, imo).

I compare this to parser combinators (like parsec) and PEGs (like luapeg and
rust-peg). I find these other options are more naturally side-effect free,
both internally and externally.

