Discussion on:

What is BNF, and why should developers care?

... that I've heard a number of times, but never looked into. Thanks!

J.Ja

Chip,

Thanks for this article. I'm looking forward to the next one(s) in the series.

I inherited some code for a commercial application and the biggest aid in understanding the application and communicating with other developers was to create a specification document. It wasn't BNF, but it forces everyone to agree to the command formats and meanings.

First let me say that this was a very insightful article. I have seen something like this before, but never really looked into it; so thanks for the great intro. However, after reading I am still asking "why should I (a developer) care?" I was hoping that would be answered, perhaps in a future article?

unless you've had already tried to develop something where it would have come in damn handy.

Have a wee go at say developing something that can parse simple formulae
C = A + B
C = A + -B
C = A + (-B)
etc
BNF gives you a formal way of describing all the legal combinations, even more valuable in my opinion, using BNF can highlight syntactic and semantic ambiguities in waht you are trying to parse, so it's invaluable for designing things you will want to write a parser for.
Then you don't have to piss about parsing context sensitive stuff
like = for assignment versus = for equality, which is a major PIA when you get the to nitty gritty of coding it.

Agreed, though in the modern programming context it seems highly academic. Still a very good article, even if the vast majority of programmers will never implement a language or interpreter outside of university.

off a kitchen sink, with a pair of grips or an adjustable wrench. You know laid on your back, water dribbling on your head, blood from barked knuckles dripping down your wrist, your missus asking you if she should ring the plumber, been under there half an hour and you think you might have tightened the thing by at least a quarter of a turn. I mean it's only a tap ffs...

If you had a tap spanner, job done in minutes (as long as you remember to isolate the thing )

Not used often, but nigh on indispensable.

...I found in using yacc was keeping in mind that when I'm classifying the input, I'm dealing with a state machine (in fact, two state machines: a tokenizer, and the parser). I wonder if it would've been better to draw out each of the rules in a state diagram until I got used to the idea.

Many years ago I was trying to convert a C-coded language parser into BNF, and I ended up throwing out some language features, because I was running into shift-reduce (one rule allows a token to be shifted onto the stack, another allows a reduce action to a non-terminal with the same token) and reduce-reduce conflicts (two or more rules reduce to a non-terminal on the same token, and the parser generator can't decide which to choose), and I couldn't figure out how to resolve them. Looking back on it now, I think the problem was caused by how I classified the input, and probably my unsophisticated use of regex's (using lex).

With most expressions it's easy to express the beginning and the end of the expression you want to match, but sometimes the specification for a part of the language is vague enough that a beginner can fall into traps. A really frustrating thing for me used to be that I'd give a regex that matched what I wanted, but it also matched stuff that came after it. So I had to tell the tokenizing state machine when to stop! You see that in one of Chip's examples (though he was dealing with the parser state machine).

The language I dealt with described reports. One of the original features was plain text that could be inserted as a block among data elements. The syntax caused problems for me, because each line of a block began with a "+", and was followed by a line of text, like a comment in code. I don't remember why, but it was interfering with the design of the rest of my BNF spec. I might've tried to simplify and optimize too soon. Hey, reminds me of Chad's recent post.

Another challenge was in trying to put out clear error messages. If someone fed some syntactically incorrect text into the parser, the best I could put out was "syntax error." I might've been able to give the line number, but it was really difficult (given my limited knowledge of how yacc worked) to get the parser to be clearer about what was wrong with the line. There was a special "error" token I used, but it didn't seem like I could do a lot with it in the BNF spec.

Thanks. I was looking forward to this article, and it was much more clearly stated than I expected.

Enjoyed reading it. Made me thing of xml and their schemas, which my limited exposure, perform a similar task...but perhaps they lean more towards defining the structure of the document, than the formats of teh strings within...