Following on from my posts on creating hashes (dictionaries) using lambdas (here, and here) and the little annotations "framework" I produced (here and here) which leverage the idea for annotating classes via extension methods... I've decided to turn my hand to creating a DSL using lambdas, on my continuing theme of C# 3.0 lambda abuse.
So first off... go have a look at Ayende's post DSL Support for brail ... that'll give you an idea of kinda what I'm trying to achieve.... so, here's an example of a simple DSL for building say a html table.
var dsl = new StandardDsl();
dsl.Add(
table => dsl.As(
tr => dsl.As(
td => dsl.Text("header1"),
td => dsl.Text("header2"))));
Console.WriteLine(DslToXml.ToXml(dsl));
which gives an output of:
<table><tr><td>header1</td><td>header2</td></tr></table>
Depending on taste you could lay it out differently, avoiding the mess of closing parentheses at the end of the Add call, say like:
var dsl = new StandardDsl();
dsl.Add
(
table => dsl.As
(
tr => dsl.As
(
td => dsl.Text("header1"),
td => dsl.Text("header2")
)
)
);
Which is pretty easy on the eyes... now what about something a little more domain specific like the view component example Ayende gave for monorail... well here's my take on that, so say we have some people:
var people = new List<Person>()
{
new Person() { FirstName = "Alex", LastName = "Henderson"},
new Person() { FirstName = "Joe", LastName = "Bloggs"}
};
And we have a DSL specific to components...
var compDsl = new ComponentDsl();
compDsl.Add
(
GridComponent => compDsl.As
(
compDsl.Component(source => people),
header => compDsl.Section
(
tr => compDsl.As
(
th => compDsl.As
(
compDsl.Text("Names")
)
)
),
item => compDsl.Section
(
tr => compDsl.As
(
td => compDsl.As
(
compDsl.Item<Person>(p => p.FirstName + " " + p.LastName)
)
)
)
)
);
And now we could do this in-line with a bigger DSL for say a whole view, but we can also just reference them so I could do something like this to create the overall view:
var dsl = new StandardDsl();
dsl.Add
(
html => dsl.As
(
body => compDsl
)
);
Now once I've tidied the code up a bit I'll probably put it up for people to have a play with - I don't necessarily consider a "good idea" - but it's cute. However for now let's have a quick look at how I'm doing it...
So to start with we have a delegate called "Batch" with the signature below - batch probably isn't the right name for this, I'm not really sure it matters all that much.
public delegate Batch[] Batch(Batch batch);
Batch takes a Batch and returns an array of Batch ;o) and to match that we then have say the "As" method on the DSL:
public Batch[] As(params Batch[] batches)
{
Batch asBatch = new Batch(delegate(Batch ignore)
{
ExecuteBatches(batches);
return null;
});
IgnoreBatch(asBatch);
return new Batch[] { asBatch };
}
Notice it takes one or more Batch instances, and returns a delegate which executes the batches, ignores the batch we just generated and returning the one Batch as an array... conforming to the expected return type of the Batch delegate. Clear as mud? ;o)
Ignoring the batches actually just uses the annotation framework, so IgnoreBatch looks like this:
public void IgnoreBatch(Batch batch)
{
batch.Annotate(Ignore => true);
}
And then we check if a batch is ignored before processing it down the line by calling this method.
public bool IsBatchIgnored(Batch batch)
{
return batch.HasAnnotation("Ignore");
}
Last of all to actually "render" the DSL into some useful format we execute it (no Expression<>'s required, so it's very fast) ... which just call the top with null, which in turn calls the arguments, and those arguments arguments etc. While doing that we write nodes (much like an Xml writer) against an "evaluation" scope, which associates a NodeWriter with the current thread.... basically the DSL ends up as a bunch of calls like:
NodeWriter writer = new NodeWriter();
writer.WriteStartNode(new NamedNode("table"))
.WriteStartNode(new NamedNode("tr"))
.WriteStartNode(new NamedNode("td"))
.WriteNode(new TextNode("column1"))
.WriteEndNode()
.WriteEndNode()
.WriteEndNode();
where the nodes conform to this interface:
public interface INode
{
INode Parent { get; set; }
List<INode> Nodes { get; }
}
At which point it's trivial to walk the tree of INode's and do whatever you like with the information stored within it, and we can encapsulate new concepts by creating new types of node, which have payloads of additional information.
At any rate, next time I'll post a little more about how I'm doing it, and attach the code for people to have a play with.