POpossibilistic·Sep 5, 2014
Except we are computer scientists and there is no BNF grammar (or what have you) for the language. We all know we can do better than that. I'm just shocked this omission went for so long without anyone noticing--it's a big freaking deal.
Formalization of a grammar isn't "design by committee" (and in any case, this work in particular certainly was not). Formalization sets a logical, mathematical foundation for something that has thus far been a rather back-of-the-napkin, cowboy coded, cargo cult kind of thing. Could you name all the terminals before? I couldn't.
Markdown is implemented in hundreds of places (conservative guess). Discounting marked deviations and well-known dialects, it is a nontrivial task to ascertain whether a given Markdown implementation will produce the "correct output". What is correct output? Our ability to express
Read the rest
or ascertain that is complicated by the fact that some rather archaic perl code [1] somehow holds the dubious distinction of being the de facto standard reference point for Markdown. Perhaps it was chosen as such on account of being the first mover, but probably its because nobody else had spoken up yet. (We're playing catch up now.)
"Implementation defines the standard" is a poor substitute for formality and is the result of intellectual laziness. (Hello PHP prior to HHVM.)
How did any of us effectively communicate what we thought correct meant? I feel a lot of our consensus was arrived at by enumerating all the examples and complex edge cases we could think of. (There's an idea that'll cover all the bases, yet it still maintains the niceties of being wonderfully concise!)
A formal grammar, as it turns out, is rather usually concise by nature (at least for the types of languages we care to design). To the attentive and deliberate thinker, a grammar's rules can be beautiful. A random mental walk through a complex repeating parse tree fills the mind all at once with intracate patterns and possibility. These are structures you can truly grok. With just pen and paper, or a standard text editor, you can easily define how the edges and vertices of an arbitrarily complex, infinite graph can connect. It's really kind of special, and definitely cerebral.
So now that we have a Markdown grammar to look to, libraries now have an easy model for attaining consensus agreement.
Nobody is going to force anyone to change their current implementation or preference. If you like the one you've got, that's perfectly valid state to be in. If your only objection to the new formalization is because it was named the so-called "standard grammar," it's just a name. A silly old case of primate chest pounding, at that. Great ape problems.
Despite all the drama, this spec will probably not be the final end-all, be-all of 80 character wide expression. I can picture infinitely many such grammars, each one being just a little more absurdly named than its predecessor. Nothing is stopping you from forking "standard markdown" and calling it MarkyMark or something.
I still can't believe none of us ever noticed there wasn't a grammar for this. Especially given we communicated all of it through bloated Perl code shared from a zip file.
[1] https://github.com/rtomayko/shocco/blob/master/Markdown.pl
(Sorry for the non-canonical link; I'm on my phone. Google search results mention a downloadable on Gruber's site, but I could be wrong.)