As some readers have noticed, I’ve been conspicuously silent since I moved over to the Oslo team. Some of this had to do with getting onto a new blogging engine, some of it had to do with various distractions like jury duty, but a lot of it had to do with the fact that Visual Basic 10.0 has gotten to a pretty stable state (so there isn’t so much for me to say any more) and I am just getting off the ground with Oslo. Not having much useful to say, I figured I’d be better off saying nothing at all rather than continuing to blather on and on about nothing in particular (that’s what Twitter is for).
Part of the process of moving over to Oslo was figuring out exactly what my role was going to be. There’s lots of cool stuff going on and a lot of smart people with strong ideas about things, so I knew it would take a while for things to settle out. Things will still probably evolve over time, but the area I’ve spent the most time on, and the thing I’ll have the most influence on for the time being, is MGrammar. It’s been an interesting experience because I’ve had to relearn a bunch of the theory around parser generation that I had forgotten in my time in VB (since we had a hand-built recursive descent parser). But it’s been enjoyable, and I think there are a lot of neat things we can do with it. So stay tuned on that.
Someone forwarded me Kevin Moore’s 20 questions/thoughts around MGrammar, and I thought answering some of those questions might be a good entree into blogging about my new job. I won’t address all of his questions, but the interesting ones, in my opinion, were:
Could C#/VB implement their compilers using MGrammar? Should they? Would they?
I believe that, as the languages stand today, C# could implement their parser using MGrammar but VB couldn’t. The reason why VB couldn’t is a pretty technical issue relating to the embedding of XML into VB which we may end up solving as well, but given the hacks that we (VB) had to do to the hand generated parser to get it to work I don’t think that reflects badly on MGrammar (or VB for that matter). The bottom line is that the parser generator is certainly powerful enough to handle an industrial-strength language. Whether the C# or VB teams should or will do anything with MGrammar is really a question for them. Both languages have hand-built parsers which allows an extraordinary degree of control over the behavior of a parse and, in particular, error messages and error recovery. They may be loath to give that up, but we’ll see.
Where is the MGrammar for C#? .for VB? .for CSV? .for VS solution files? .for XML?
In general, the Oslo team is just one little team and can only do so much. Although we endeavor to provide you with the maximum number of samples, in truth we are limited in what we can do at any one time. You should expect to see more samples as time goes on. I’ll also note, though, that some of those languages do present interesting challenges to a parser generator. I’ve already covered VB, but XML also has challenges, which I think is really a subject for another entry.
There should be standardized or defacto escape mechanisms for existing grammars.
If I understand the point here correctly, what’s really being asked for is composability of grammars. This is a difficult, but interesting, area of work. To use an example I’ve already referenced, there were a lot of challenges integrating XML into VB because the languages were very different, even down to the lexical level. Having languages compose in some kind of simple way (even to do things like add or override parts of an existing grammar) is an open question that we’re very interested in but we’re still working on.
Will there be tools to go back from a logical model (MSchema) to the input format?
This is on our radar, but we don’t have an answer at the moment. It’s a very natural and logical thing to do, but (of course) running a grammar in reverse is not a trivial matter. I’m not sure we can get to a point where we can reverse a parse automatically, but we do want to provide people with a way to do this in as simple a manner as possible.
Where is the community site for MGrammar?
Well, we’ve got the Oslo Developer Center and the Oslo forums. If you want to start a community site, by all means go ahead!
Any news with Mono? Is Miguel interested?
I think you’d have to ask Miguel that.
Are you making a play to make MGrammar a standard? I’ve heard yes, but just wanted to confirm.
What we’ve committed to is releasing the MGrammar specification (well, actually, the whole M language specification) under the Open Specification Promise. That’s the only commitment we’ve made so far regarding MGrammar’s specification, but it’s a pretty big one.
How is the computer science behind MGrammar?
Pretty good, and I expect it to get even better. Expect to hear more here and elsewhere about internal specifics as time goes on (it’s a little more than can be covered in one blog post).
I hope that answers some questions, and feel free to ask more questions here or on the forums. Thanks!
Pingback: Jason Haley
“I’ll also note . that some of those languages do present interesting challenges to a parser generator. . XML also has challenges, which I think is really a subject for another entry.”
I’m very intrigued by this. I haven’t thought it through but I actually think that XML should be relatively straightforward to implement. Certainly, hand-writing a parser for XML is quite easy (disregarding any encoding issues).
So I at least would be very interested in a follow-up entry detailing some of the problems concerning XML.