Talk:GNU Bison

Computing: Software Stub‑class

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Stub	This article has been rated as Stub-class on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.
	This article is supported by WikiProject Software.
	This article has been automatically rated by a bot or other tool as Stub-class because it uses a stub template. Please ensure the assessment is correct before removing the `\|auto=` parameter.

What this page needs

This page needs a few things, IMHO:

Description on Bison's history, its makers, and who is using it right now (the programming language Ruby is created using bison, for instance)
A piece of grammar, and a text to explain that grammar (some stuff could be found a the Introduction to Bison

I started a "Who is using it" section. It lacks a lot of real-world usage, though. Espadrine (talk) 13:07, 1 July 2011 (UTC)[reply]

More Explanation

Agreeing with the above, I believe more explanation of where it stands in the whole perspective of the parsing process. It says it is used along with flex, but what role to each play with each other.

jptdrake 18:11, 4 February 2007 (UTC)[reply]

Circumstance hereby elects you to do improve this in a small or large way. Gronky 19:00, 4 February 2007 (UTC)[reply]

Word play

Yak / bison, now I got it. --Abdull (talk) 10:37, 26 February 2008 (UTC)[reply]

I notice that the source of the name is not mentioned anywhere in the article. I would think that the above is correct and it is a play on yacc/yak, but I can't find any sources that explicitly say so. Are there any? - Paul Richter (talk) 04:43, 25 January 2012 (UTC)[reply]

http://www.developer.com/net/cplus/article.php/3642516/Classic-Parsing-with-Flex-and-Bison.htm would suffice. Probably there are no authoritative sources TEDickey (talk) 09:21, 25 January 2012 (UTC)[reply]

You might find this helpful: http://tvtropes.org/pmwiki/pmwiki.php/Main/DontExplainTheJoke TEDickey (talk) 09:39, 25 January 2012 (UTC)[reply]

GCC

This current article states that "GCC" once used Bison but later switched. However, the provided reference (a mailing list post made before the work even happened) only refers GCC's C++ front-end and specifically states that (at the time) they had no intention of replacing the C parser.

I haven't taken the time to research whether or not Bison was replaced wholesale or just for C++. However, What "GCC" actually refers to should probably be clarified and matched with a more appropriate reference. -- Craigbarnes85 (talk) 09:43, 11 August 2011 (UTC)[reply]

Is Bash's distribution of generated files special?

In the list of applications using Bison, I removed this from the entry about Bash:

It is distributed with Bison-generated files.

I guess this is referring to distributing Bash's source code. I.e. Bash probably distributes the C files generated by Bison so that others can recompile Bash without having to have a compatible version of Bison installed. (This is in addition to Bash distributing the parser source code that gets fed into Bison, as required by the GPL.)

AFAIK, this is common practice, so it should be a general comment in the article rather than just being attached to Bash. I'll do that now. Just wanted to leave a note in case I'd misunderstood. Can someone reply to say I've got this right/wrong? Gronky (talk) 23:19, 4 August 2013 (UTC)[reply]

bash's use of bison

A quick check of bash 4.1's source shows that while it is distributed with parse.c and parse.h generated by bison, it is not using any bison-specific features. So the "use" is only superficial (and unless commented on more explicitly, the tie-in can be removed). TEDickey (talk) 23:25, 4 August 2013 (UTC)[reply]