source code => "Lambda based DSL"

So I've tidied up the source for the DSL from my last post a little... though my "test" was to represent a DSL
similar to the one Ayende displayed in
Brail - I haven't implemented any monorail view engine
integration, there's little point I feel, I was more interested
in being able to display a nested DSL-like syntax, and parse the
necessary information out of it as required. 



You can grab it from SVN repository
target="_blank">here (edit: I've now fix the PROPFIND proxy
issue, so the link should work)



At any rate, probably the most interesting example is the one
that takes this code:

var people = new List()
{
new Person() { FirstName = "Alex", LastName = "Henderson"},
new Person() { FirstName = "Joe", LastName = "Bloggs"}
};

var compDsl = new ComponentDsl();

compDsl.Add
(
GridComponent => compDsl.Component
(
compDsl.Parameters
(
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(p => p.FirstName + " " + p.LastName)
)
)
)
)
);

var dsl = new StandardDsl();

dsl.Add
(
html => dsl.As
(
body => compDsl
)
);

And converts it to this xhtml...






Names
Alex Henderson
Joe Bloggs



You can pretty quickly figure out what's going on by placing a
breakpoint on the Execute() method of the StandardDsl class and tracing through all the calls - in
essence all the nodes are emitted by calling the top-level Batch
delegate which causes a recursive call down the "tree", with the
information being emitted as a side-effect to an evaluation
scope.



Though I used nodes - effectively creating a structure that's
easier to parse, there's no reason why you couldn't make
immediate calls to some kind of object, avoiding the need for a
second round of parsing - the only trick is that you'd still need
to use some kind of scoped stack to push/pop the names of the
components because in a statement like this:

dsl.As
(
GridComponent => dsl.Component
(
// etc. etc.
)
)



the call to dsl.Component needs some way to inspect the
stack of names and pull "GridComponent" off the
top.



I'd love to hear from anyone who could see a use for this kind of
thing... it'd be nice to get a more realistic example... I'm
struggling to think of anything practical myself.

[Edit: I Noticed the code formatting was pretty awful, so
I've tidied it up a little... anyone got a good solution for
copy/pasting code out of orcas (CopyAsHtml2005 doesn't appear to
install under Orcas)]

Read More

Getting your DSL on...

Following on from my posts on creating hashes (dictionaries) using lambdas (here, andhere) 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:

header1 header2

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()
{
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(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:

code>
public interface INode
{
INode Parent { get; set; }
List 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.

Read More

For future reference...

No so much for my future reference, but to refer people too should the topic of how generic types are represented by name ever crops up again.










Type FullName
typeof (List<>).FullName System.Collections.Generic.List`1
typeof(List).FullName System.Collections.Generic.List`1[[System.Int32]]
typeof(Dictionary<,>).FullName System.Collections.Generic.Dictionary`2
typeof(Dictionary).FullName System.Collections.Generic.Dictionary`2[[System.String],[System.Int32]]
typeof(Dictionary<>>).FullName System.Collections.Generic.Dictionary`2[[System.String],[System.Collections.Generic.List`1[[System.Int32]]]]
Read More

briefly hacked...


My aging dasBlog install got hacked last night some time... by the turks ;o) all back up and running again now, upgraded to dasBlog 1.9 as well... might migrate to a different blog platform at some point (either Subtext, or I might give nBlogr a whirl because I know the technology stack it sits on reasonably well.

Read More

Annotations - here's the code

Here's the code for my last post on Annotations - I tidied up a few things up (it's still very basic but it does work) there's a single test fixture to give you a guide for usage... so things like:

    [Test]
public void QueryStoreForClassAnnotationsWithCertainKey()
{
ClassA target1 = new ClassA();
ClassA target2 = new ClassA();
ClassA target3 = new ClassA();
target1.Annotate(Description => "class number 1");
target2.Annotate(Description => "class number 2");
target3.Annotate(Parsed => true);

var results = AnnotationStore.Classes
.Where(a => a.HasKey("Description"))
.ToList();

Assert.AreEqual(2, results.Count);
}

And also the equivalent thing is possible for members... though I suspect annotating members isn't all that useful in most cases...

  [Test]
public void QueryStoreForMemberAnnotations()
{
ClassA target1 = new ClassA();
ClassA target2 = new ClassA();
ClassA target3 = new ClassA();

target1.Annotate(() => target1.FirstName,
CamelCase => true); // annotating a property
target1.Annotate(() => target1.Field,
Ignored => true); // annotating a field
target2.Annotate(() => target2.Execute(),
Parsed => true); // annotating a method
target3.Annotate(Parsed => true);

var results = AnnotationStore.Members
.Where(p => p.HasKey("CamelCase"))
.ToList();

Assert.AreEqual(1, results.Count);
}

Read More