Pinky's

DynamicObject over M values

2009-11-18T11:10:00.001-08:00

If you've used our bits, then for sure you have played with the DSL features.

If you haven't, it lets you create a DSL to process text and produce structured data.

With dynamic object support in .Net 4.0, we can add the ability to interact with that data as if it were objects in the CLR.

The code below is just such a little library that lets you do so. Don wrote it last night to help out with our PDC talk today.

Try it out!

// implementation of .NET 4.0 dynamic object over Node/Edge data model

// provides a read-only object-based view over M values

namespace Microsoft.M

{

using System.Reflection;

using System.Dataflow;

using System.IO;

using System.Dynamic;

using System;

using System.Collections;

using System.Collections.Generic;

public class DynamicObjectNode : DynamicObject

{

Node node;

// we never want to double-wrap, so all construction

// goes through NodeToObject, which unwraps atomics

internal DynamicObjectNode(Node node)

{

this.node = node;

}

// this method is the only way to go from the low-level

// node world to the world of (dynamic) objects

public static object NodeToObject(Node node)

{

if (node.NodeKind == NodeKind.Atomic)

return node.AtomicValue;

else

return new DynamicObjectNode(node);

}

public static IEnumerable<dynamic> ReadValues(TextReader reader)

{

foreach (var edge in Node.ReadFrom(reader))

{

yield return NodeToObject(edge.Node);

}

public static IEnumerable<dynamic> ReadValuesFromString(string text)

{

foreach (var edge in Node.ReadFromString(text))

{

yield return NodeToObject(edge.Node);

}

// implement the obvious three...

public override bool Equals(object obj)

{

return node.Equals(obj);

}

public override int GetHashCode()

{

return node.GetHashCode();

}

public override string ToString()

{

return node.ToString();

}

public Identifier GetBrand() { return node.Brand; }

// special case conversion to IEnumerable to support foreach

// over lists and collections

public override bool TryConvert(ConvertBinder binder, out object result)

{

result = null;

if (binder.Type != typeof(IEnumerable))

return false;

switch (node.NodeKind)

{

case NodeKind.Collection:

result = WrapCollectionNodeAsEnumerable(node);

return true;

case NodeKind.List:

result = WrapListNodeAsEnumerable(node);

return true;

default:

return false;

}

IEnumerable WrapCollectionNodeAsEnumerable(Node node)

{

foreach (var item in node.Edges)

{

yield return NodeToObject(item.Node);

}

IEnumerable WrapListNodeAsEnumerable(Node node)

{

foreach (var item in node.ViewAsList())

{

yield return NodeToObject(item);

}

// support [int] over list and [string] over records

public override bool TryGetIndex(GetIndexBinder binder, object[] indexes, out object result)

{

result = null;

if (indexes.Length > 1)

return false;

if (node.NodeKind == NodeKind.List && indexes[0] is int)

{

int index = (int)indexes[0];

var list = node.ViewAsList();

if (index >= list.Count)

throw new IndexOutOfRangeException("Indexed past end of M list node");

result = NodeToObject(list[index]);

return true;

}

string name = indexes[0] as string;

if (name != null)

{

return TryGetMember(name, true, out result);

}

return false;

}

// support . over records and .Count/.IsReadOnly over collections/lists

public override bool TryGetMember(GetMemberBinder binder, out object result)

{

return TryGetMember(binder.Name, binder.IgnoreCase, out result);

}

bool TryGetMember(string name, bool ignoreCase, out object result)

{

result = null;

switch (node.NodeKind)

{

case NodeKind.List:

if (name == "Count")

{

result = node.ViewAsList().Count;

return true;

}

else if (name == "IsReadOnly")

{

result = true;

return true;

}

return false;

case NodeKind.Collection:

if (name == "Count")

{

result = node.Edges.Count;

return true;

}

else if (name == "IsReadOnly")

{

result = true;

return true;

}

return false;

case NodeKind.Record:

if (node.Edges.ContainsLabel(name))

{

result = NodeToObject(node.Edges[name]);

return true;

}

else if (ignoreCase)

{

foreach (var e in node.Edges)

{

if (string.Compare(e.Label.Text, name, StringComparison.InvariantCultureIgnoreCase) == 0)

{

result = NodeToObject(e.Node);

return true;

}

return false;

default:

return false;

}

public class Language

{

MImage image;

GraphStore store = new DefaultGraphStore();

string moduleName, languageName;

ParserFactory factory;

internal Language(MImage image, string moduleName, string languageName)

{

this.image = image;

this.moduleName = moduleName;

this.languageName = languageName;

this.factory = this.image.ParserFactories[moduleName + "." + languageName];

}

internal Language(Assembly assm, string moduleName, string languageName)

: this(MImage.LoadFromAssembly(assm), moduleName, languageName)

{

}

public MImage Image { get { return this.image; } }

public string ModuleName { get { return moduleName; } }

public string LanguageName { get { return languageName; } }

public static Language Load(MImage image, string moduleName, string languageName)

{

return new Language(image, moduleName, languageName);

}

public static Language Load(Assembly assm, string moduleName, string languageName)

{

return new Language(assm, moduleName, languageName);

}

public static Language LoadFromCurrentAssembly(string moduleName, string languageName)

{

var assm = Assembly.GetCallingAssembly();

return new Language(assm, moduleName, languageName);

}

public dynamic ParseString(string text)

{

return Parse(new StringReader(text));

}

public dynamic ParseString(string text, ErrorReporter errors)

{

return Parse(new StringReader(text), errors);

}

public dynamic ParseString(string text, ErrorReporter errors, string fileName)

{

return Parse(new StringReader(text), errors, fileName);

}

public dynamic ParseString(string text, ErrorReporter errors, string fileName, SourcePoint startLocation)

{

return Parse(new StringReader(text), errors, fileName, startLocation);

}

public dynamic Parse(TextReader reader)

{

return Parse(new TextReaderTextStream(reader), ErrorReporter.Standard);

}

public dynamic Parse(TextReader reader, ErrorReporter errors)

{

return Parse(new TextReaderTextStream(reader), errors);

}

public dynamic Parse(TextReader reader, ErrorReporter errors, string fileName, SourcePoint startLocation)

{

return Parse(new TextReaderTextStream(fileName, reader), errors, startLocation);

}

public dynamic Parse(TextReader reader, ErrorReporter errors, string fileName)

{

return Parse(new TextReaderTextStream(fileName, reader), errors);

}

public dynamic Parse(ITextStream stream, ErrorReporter errors)

{

var parser = CreateParser();

var result = parser.Parse(stream, errors);

return NormalizeResult(result);

}

public dynamic Parse(ITextStream stream, ErrorReporter errors, SourcePoint startLocation)

{

var parser = CreateParser();

var result = parser.Parse(stream, errors, startLocation);

return NormalizeResult(result);

}

System.Dataflow.Parser CreateParser()

{

var parser = factory.Create();

parser.GraphBuilder = new NodeGraphBuilder(store);

return parser;

}

dynamic NormalizeResult(object result)

{

if (result is Node)

return DynamicObjectNode.NodeToObject((Node)result);

return result;

}

Hanging out at PDC 09

2009-11-18T10:58:00.001-08:00

Hey - I'm at PDC 09. Stop by the booth if you want to chat about all things "M".

PHP popularity...

2009-08-12T21:55:00.000-07:00

Interesting thread on how PHP got to be popular.

In summary

- drop features if they contribute the least to producitivity

- fabulous docs

- "killer" framework/scenario (VB + Forms, Ruby + Rails, PHP + Web apps)

Languages and game development

2009-08-12T06:21:00.000-07:00

I'm reading through an interesting ppt on a game developer's view of language problems with C++.

http://lambda-the-ultimate.org/node/1277

I found this interesting:

§ Usage of integer variables in Unreal:

– 90% of integer variables in Unreal exist to index into arrays

• 80% could be dependently-typed explicitly,
guaranteeing safe array access without casting.

• 10% would require casts upon array access.

– The other 10% are used for:

• Computing summary statistics

• Encoding bit flags

• Various forms of low-level hackery

§ “For” loops in Unreal:

– 40% are functional comprehensions

– 50% are functional folds

The Natural Numbers

Factoid: C# exposes more than 10 integer-like data types, none of which are those defined by (Pythagoras, 500BC).

In the future, can we get integers right?

And this:

Concurency in Numeric Computation

· These are essentially pure functional algorithms, but they operate locally on mutable state

· Haskell ST, STRef solution enables encapsulating local heaps and mutability within referentially-transparent code

· These are the building blocks for implicitly parallel programs

· Estimate ~80% of CPU effort in Unreal can be parallelized this way

M interop with XML (and others)

2009-05-28T08:18:00.001-07:00

Someone asked a great question on the MSDN forums -

looking at the current bits i can see a transform from M to XML.
But what seems to be missing is a transform from (XSD+XML) => M Schema + M
Any plans for this?
I think you need to support this scenario as most metadata (or models as you call them)
is now encoded as XML

I like to think of M interop with other data formats in two very interesting and different scenarios.

One is exactly what Tim asked about - how do we take M data (which we call MGraph) and interoperate with other data formats, such as XML? Truthfully the mapping is pretty straight forward and we've prototyped it enough and have an initial implementation. It needs improved engineering before we declare ship ready, but there you have it.

We also think about interop at the schema level. For example, if we transform an MGraph to XML, then wouldn't it be great to transform the representative schema for that data into XSD? That's something we haven't quite done yet, but again I don't think that it would be hard, just work. We don't really have that booked to implement right now. Do people see a huge need?

Also, there's interop at the grammar level. This is probably not something we talk about much because there you really need to consider functional mapping. In other words, a grammar is just a function from character* to structured data (MGraph). Mapping that from one language like M to another like XSLT is quite a complicated problem and not likely something we'll tackle outside of research interests.

Now, there's another really big set of scenarios, quite orthogonal to the external interop ones above. I call these internal interop, or how to enable embedded DSLs or user-defined data structure and types within M. Sounds quite mystical and abstract :)

It means a couple of things. First, what if you wanted to write your own syntax for values inside of an M program. For example, suppose we didn't have a GUID type nor a textual representation for GUID values. Wouldn't it be great if you could tell M - "hey this is my syntax for my data"? We're thinking about that scenario, but nothing is committed to implementation yet.

Second, what if you could write your own DSL inside of M that would produce the equivalent of M program constructs, such as types and functions. This is what we call 'meta-programming'. We have lots of dreams to do this, and we're working towards that, but it's most likely a V2 priority not a V1 priority.

As always - I'd love your feedback on this.

Ewald on Dynamic languages

2009-05-22T22:52:00.000-07:00

Great post by Tim on why you should learn a dynamic language.

Do people think M is a dynamic language?

What's the purpose of types?

2009-05-22T22:25:00.000-07:00

Do programmers always grok the purpose of types (nominal or structural)?

What if I didn't use the word 'type'?

What if I used the word 'pattern'? Or 'constraint'? Or 'rule'?

What if I used the word 'allocator'? Or 'constructor'?

What does it mean to you?

Structural versus Nominal typing

2009-05-22T07:40:00.000-07:00

M has a structural type system. Most programming languages today, and in particular most OO languages, have a strict nominal typing system.

Given that types are used in 2 ways (validation/constraints and value construction), how do programmers generally feel about one versus the other?

Do programmers need both? In which case is one better than the other?

Do programmers really understand both?

I'd love your thoughts.

M Past and Present

2009-05-22T07:38:00.000-07:00

Let's talk a little about M's past and present.

At PDC 08, we introduced M as a way to write down data (Mgraph), schema and functions about that structured data (Mschema), and character parsing into structured data (Mgrammar).

Frankly, at PDC, we tried to tell a '1 language with 3 parts' story, but in my opinion it was more like a '2 languages with similar concepts and marketing terms'. Truth be told, those technologies kinda grew up separate.

It doesn't matter. We showed the world some interesting ideas, and we saw how powerful it could be to bring the pieces together.

We've been working hard at that - at integrating the languages. As I type, some of the smartest folks I know are busy rebuilding the internals of the compiler. We hope to be able to bring all of the parts together as close as we can before the next PDC. I can't wait to illustrate some of the key customer scenarios we expect to get with that integration.

Our first step to integrate the language will be visible to everyone in our next CTP drop. We deleted mg.exe, the compiler tool for Mgrammar. Now, you can use a single executable and API to compile Mschema or Mgrammar programs. You still have to have separate file extensions (.mg for Mgrammar, .m for Mschema).

We almost deleted mgx.exe as well, but we weren't able to get all of that work done.

Now - what happens after we integrate the language? I'll talk more about that in the future. And, I'll talk about other innovations we'll be seeing in the language - some of them before PDC 09, but maybe not until after.

Stay tuned.

"Reflection" in M

2009-05-16T15:41:00.000-07:00

Wouldn't it be great if you could use reflection to inspect your M program, and add additional data to it. For example, suppose you wanted to add additional metadata to a type declaration, or a computed value.

In the upcoming release of the Oslo CTP, we introduce a new thing we call the M catalog, along with an operator in M called 'about'.

The M catalog is simply a structured representation of an M program, or what we call the M semantic graph. The schema for the catalog is written in M, and the compiler can generate instances of your M program into that schema. Then it just shows up in the database using mx.exe.

Right now, the way to create an image with the M catalog schema is to run m.exe with the 'catalog definition' parameter, or 'catdef' for short.

m.exe -catdef -out:catalog.mx

This creates an image that contains extent declarations for things like Modules, Types, Extents, and Computed Values. The catalog also has various helper computed values for querying the catalog. For example, you can ask if a particular computed value is installed (IsComputedValueInstalled). Or, you can ask if a type is an intrinsic, collection or entity type (IsIntrinsicType, IsCollectionType, IsEntityType). Or, one of my favorite, you can ask for all of the references to an extent ('ReferencesToExtent').

For now, we don't automatically generate instances for a given M program. You have to explicitly ask for it, and you have to reference the catalog definition generated above. We hope to fix all of that in the next milestone and turn it on by default. Here's a simple example for how to create catalog instances for your M:

m.exe myM.m -catalog /r:catalog.mx

When you run mx with myM.mx and catalog.mx, the M catalog will show up in the database. After you load, take a look at the database. In particular, one super cool thing is that the catalog also maintains the relationship between the SQL created from the M and their corresponding M declarations. For example, take a look at Tables, Functions, and Views in the Language.Catalog.SQL namespace.

That's a brief intro to the M catalog. There will be lots of scenarios coming where we use the catalog to query, analyze and understand M.

What if you want to access the catalog from your M program? That's easy enough because the catalog is written in M. So, you can reference and query the extents directly, or call one of the computed values.

The coolest reason to do this is to add additional data to your M program. This is what some people call metadata - although I'm not very fond of that term (it's all just data). Let's start with an example.

Let's start with one of our classic Oslo scenario models, the WIX model. Let's suppose that I am building a super-duper add-in to WIX that will deploy M to a database. The problem is that the WIX model does not include database deployment information. I could update the WIX model to include this, but that's not a great extensibility story for our developers. Instead, I will build my own little model for my specialization, I will reference M content in the catalog, and I will use about to write instances that reference specific values in the catalog.

Here's a simple version of my model. It describes additional information that I want to associate with a module in M:

module MDeployer

{

import Language.Catalog;

DatabaseConfigurations : ({

Id : Integer32 => AutoNumber;

DatabaseName : Text;

ServerName : Text;

Module : Modules;

} where identity Id, value.Module in Modules)*;

}

Now, I want to write a deployment package the says that a particular M module is deployed to a particular server and database. Here's an example, except what do I write to specify the module name?

module DeploymentPackage

{

import MDeployer;

import MyModel;

MDeployer::DatabaseConfigurations

{

{ DatabaseName => "Testdatabase", ServerName => "TestServer", Module => ... }

}

You could write a query, for example, 'Module => (Modules where value.Name == "MyModel")'. That's not always easy to remember. What's worse is that it is not strongly typed - what if I misspell "MyModel". I wouldn't find out about that until loading into the database. What I really want is a compile-time check that I have referenced the right M declaration.

'about' is the magic to make this easy. 'about' is a function that does what the query does, but it's strongly typed and uses the actual identifiers of the M declaration that you want to reference. Here it is:

module DeploymentPackage

{

import MDeployer;

import MyModel;

MDeployer::Databases

{

DatabaseName => "Testdatabase",

ServerName => "TestServer",

Module => about(MyModel)

}

In summary, about allows you to add additional data to your M that is about your M. It references that content, and when loaded to the database, references your M program that is represented in the M catalog.

New stuff coming

2009-05-14T07:06:00.001-07:00

I have not been very chatty over the last few months. We've been working very hard to rev a new version of the Oslo CTP. It should be out in the next few weeks.

So, you'll be hearing more from me. I have a number of detailed topics I want to share including new language and toolchain features such as:

i. single m.exe

ii. cycle initialization

iii. computed values in initializers

iv. extern

v. catalog and about

vi. Catalog inferrer

vii. Repository patterns via M modeling

i. sequence ID

ii. Folder

iii. Security views

viii. mx command line options, including Folder

ix. New mgraph API

Also - I suppose I should continue on with my detailed discussion of how M query expressions work.

It should be a fun couple of blogging weeks. Stay tuned.

DSLCon was awesome

2009-05-03T12:05:00.001-07:00

I attended Sells' DSLCon a few weeks ago - just now blogging about it.

Fowler's keynote was awesome. Modeling-is-programming is a key message for Oslo/M. It's our differentiation from other kinds of modeling, e.g., UML. His discussion about DSLs and semantic models to represent domains which can then be executed is spot on.

If you really want to understand Oslo and M, check out Fowler's work on DSLs.

Some of the conference was a bit too much powerpointy for me - I would prefer more code. But all-in-all a great event.

Thank you sells! You are the man.

What's up

2009-03-30T14:29:00.000-07:00

The last few months I've been heads down on our next milestone working on the M compiler. We continue to make great improvements in the stability of the bits, and add new features as well.

When we release the next CTP, I'll be sure to blog about it.

Making Jon happy

2009-03-30T14:28:00.000-07:00

I'm blogging just to make Jon happy.

Blog, blog, blog...

Oslo at Mix

2009-02-11T20:57:00.001-08:00

Check it out if you can.

“M”ix09 (Using “M” to write REST services and clients)

Oslo CTP 2

2009-01-30T15:54:00.001-08:00

At PDC I told folks that we would try to release a new version of Oslo every 3-6 months.

Well, it's been 3 months and here it is!

Sells should be blogging more about this on Monday.

I'm boring

2009-01-18T20:33:00.000-08:00

My buddy says that my blog is boring.

Yo - Jon - why you gotta dis' me like that? At least my friends look better than yours.

M Data Transformation Part 1

2009-01-18T19:42:00.001-08:00

Lots of blogs and content on M spend a bunch of time focused on the modeling and DSL aspects of M. And, lots of folks always ask about data transform. So, I'm going to spend some time on transformation. Clearly, if you're working on a data-oriented platform, transformation is a key enabler.

Let's start with a couple of principles that M transforms live by:

- Functional. functional programming is the right paradigm for writing transformations because they are compositional and side-effect free

- Compositional. A corollary of functional, building transforms on top of transforms is powerful and enables reuse. It also means that clients/consumers do the same thing regardless of whether they are consuming a graph or a transform over a graph.

- Consistent. Queries are expressions that produce new values. Constraints are also expressions. We wanted the query language to be consistent withe the constraint language.

- Familiar. The syntax should be familiar to folks already writing transforms in T-SQL or in LINQ

- Ease. There are a number of shorthand forms for queries that make writing transforms even easier

OK - let's write some transforms. I'm going to use a very simple data model for my examples. Here's a model for Contacts (aka Outlook):

module Contacts

{

export People, Addresses, Zips;

People :

{

Name : Text#128;

Age : Integer32;

MyAddresses : Addresses*;

}* where identity(Name);

Addresses :

{

Id : Integer32 = AutoNumber();

Street : Text;

Country : Text;

Zip : Zips;

}* where identity(Id);

Zips : Integer32* { 98052, 44114, 44115};

}

Here are a couple of queries for the projections, i.e., selecting values from a collection. Notice that there is a long syntax and a comprehension syntax that uses value.

module CollectionQueries

{

import Contacts;

Q1()

{

from z in Zips

select z

}

Q2()

{

Zips select value

}

These are exactly equivalent. Check out the generated SQL:

create view [Queries].[Q1]

(

[Item]

)

select [z].[Item] as [Item]

from [Contacts].[Zips] as [z];

create view [Queries].[Q2]

(

[Item]

)

select [$value].[Item] as [Item]

from [Contacts].[Zips] as [$value];

Now, let's write some projections using entity collections.

module EntityQueries

{

import Contacts;

Q1()

{

from p in People

select p.Age

}

Q2()

{

People select value.Age

}

Q3()

{

People.Age

}

Again, we have a full query syntax version and a comprehension form. There's also a 3rd syntax called a projector. It returns the same results, but is written more like a function of the field name.

That's some very basics around projection. Stay tuned for posts on more complex projections, plus selection, join, and other interesting query language features.

PS. if you want to see lots of examples, check out the set of M sample queries in the SDK. We wrote all of the LINQ samples in M so you can compare.

Enjoy!

Why oslo remix

2009-01-18T11:54:00.000-08:00

This post is awesome!

Metadata or data

2009-01-11T20:59:00.001-08:00

I get quite irritated (sorry - no patience) when I hear others talk of a very distinct difference between metadata and transactional data. I really don't agree.

The arguments generally go something like this: "Metadata is mostly read-only. Transactional data is written much more frequently. Metadata has different access patterns -- I don't even know what that means :).

I find that to be hogwash. That describes usage not kinds of data. I do not like categorizing data. It's like nominal typing - limits its broader viability and usability after the fact. Any data at any given time can be more like metadata or more like transactional data. For example:

- To an engineer, bill of materials is transactional data when designing a product. But, to a resource planner, the bill of materials is metadata that drives materials planning, purchasing and manufacturing scheduling.

- A web page is transactional data during development, but metadata at runtime (unless it is self-modifying code)

So, it just depends on the usage. Don't categorize the data, just understand the usage.

As for Oslo, I assert thatwe are building a broad set of capabilities to describe, validate, transform, access, and store data. Sure, Oslo's primary scenarios and our investments right now are targeted at data that describes runtimes. However, our ambitions are bigger, and our architecture and designs not limited or miopic in our thinking. If they are - please help us. After all, data is just data.

MGrammar + MSchema example

2009-01-06T22:53:00.000-08:00

Justin asked a question about what it means to bring MSchema nad MGrammar together. Let me do a simple example to clarify.

Today I can write my semantic model in MSchema as such:

module Contacts {
type Person { Name : Text; Age : Integer32; }
People : Person*;
}

I can then write a grammar like this to generate values like this:

module Contacts {
language PeopleLang {
{
syntax Main = p:Person* => People { valuesof(p) };
syntax Person = n:Name a:Age => { Name = n, Age = a};
// elided details
}
}

There's a bunch of things that come to mind with the MGraph produced by the DSL versus the values expected by the semantic model, such as:
Type Checking
How do we statically (or dynamically) check that the values are typed correctly. For example, I want to do something like this:

syntax Person = n:Name a:Age => { Name = n : Text, Age = a : Integer32} : Contacts.Person ;

Expression support
I can build values up in MSchema using expressions and querys. Shouldn't I be able to do that on the RHS of grammars? For example:

syntax Name = f:FirstName l:LastName=> f + " " + l;

I also want to use functions and other things in the semantic model to both construct values as well as validate structural correctness.

Constraint support
Semantic models have constraints. Shouldn't values produced by MGrammar be validated against those? This is really a superset of the type check question since typing is really a form of constraint checking the structure of a value.

So, when I talked about MSchema and MGrammar integration in previous posts, I was hinting at the idea of bringing together the semantic model with the DSL declarations to ensure that the DSL output aligns with the model.

I hope that helps.

MGraph as a data rep

2009-01-06T22:38:00.001-08:00

Today we have lots of XML on the wire.

There's also lots of JSON.

I want to see MGraph get there as well. So, over the holidays I wrote GraphReader and GraphWriter. Think of these in the same equivalence class as TextReader/Writer or XmlReader/Writer.

Now - you may ask yourself - what's the difference between this and what the lexer/parser does in the M toochain to process MGraphs? Conceptually, there's no difference. But, if you really want to use MGraph on the wire, then you need something that is highly tuned, capable of streaming, and supports doing other wire reps besides text.

The way to think about this is serialization format versus program text. We want both with the same textual syntax, but the usage scenarios are different.

So, I started off building the Writer. It was easy except I started down 1 path 1st, and then had to simplify. I started off by baking in our interpretation of Record and Sequence into the serializer. It was something like this:

class GraphWriter {
void WriteStartEntity();
void WriteStartSequence();
void WriteStartNode();
// ends and other basic write statements elided
}

But then with the help of my great colleagues, I realized that I do not want this because it bakes the interpretation into the serialized format. I actually want the interpretation to be done by the reader. Also, it makes the reader much harder to write.

So, now it's just basically WriteStartNode :) It's that simple.

I also built a serializer on top of the writer that takes an IGraphBuilder and a graph node and makes the appropriate calls to serialize.

I then started on the Reader as the inverse/deserialization process. I haven't finished this yet because my hard drive is failing. I'll provide more details later.

I have no idea if we will productive this kind of thing, but I hope so in V1.

I miss chrome

2009-01-06T22:35:00.000-08:00

My hard drive is crashing. It didn't totally die, but lets just say that at random points starting up Win7, things get interesting. And, chkdsk hangs forever.

Anyways - Gudge was kind enough to lend me a machine while I get it fixed.

It doesn't have Chrome. I miss it.

Intro to Formal Type Systems

2009-01-03T11:00:00.001-08:00

Cardelli has a great introduction paper to the formalism of type systems and type theory. The math guy in me loves the theory.

M == Semantic Model + DSL + values

2009-01-02T20:24:00.001-08:00

I want to make sure I'm clear wrt my post from the other day about Fowler's work. Here's a simple formula to translate M concepts into Fowler speak:

MGrammar == DSL

MSchema == semantic model

MGraph == values of DSL/semantic model