Using MGrammar to create .Net instances through Xaml


In the last couple months I have had more fun playing with MGrammar than just about any other programming I’ve ever done, but in its current form the one thing that really feels missing to me is an easy ability to create CLR object instances.

MGrammar is great for tying in with MSchema, and you can write custom IGraphBuilder implementations for all kinds of things, but in the end most of the code I am writing is still C# and needs instances as input.

Enter Xaml, a wonderful format for writing down arbitrary .Net objects (well many of them anyway). And, it turns out that the MGraph data rep is reasonably friendly to a Xaml projection. So, now posted as a sample on the Oslo dev center is some code I wrote to enable targeting Xaml with MGrammar output.

 

Get the bits here: [updated link on 11/28, apparently the bits moved]http://download.microsoft.com/download/B/9/8/B982BFD9-3E17-426A-A537-833BEF376698/MGrammarXamlSample.msi

 

And after that go watch a couple of screen casts that I recorded about using the sample.

 

First: a very simple example of instantiating a Person object from MGrammar output: http://wm.microsoft.com/ms/msdn/oslo/PersonExample.wmv

 

This example takes a simple grammar and some input, creates a graph and then runs it through the MGraphXamlReader to create instances of the type Person (see below) which I defined in C#.

image

public class Person
{
    List<Person> children = new List<Person>();

    public string First { get; set; }
    public string Last { get; set; }
    public ICollection<Person> Children { get { return children; } }

}

 

 

A more complex example of a grammar for writing down WPF applications in an English like syntax:

http://wm.microsoft.com/ms/msdn/oslo/mwindowexample.wmv


Comments (5)

  1. An MGrammar language is effectively a function from Unicode text to an arbitrary MGraph value. Our runtime

  2. int19h says:

    It would be nice if there was a stock mapper of MGraph to F# ADTs – I would argue that F# is inherently somewhat better at processing tree structures than C#, especially when it’s done in its own terms.

  3. Nice post, it is the missing link. We were waiting for this to happen.

  4. Erics Blog says:

    From what I’ve seen of &quot;Oslo&quot;, the new &quot;M&quot; language for creating Domain Specific