Lambda the Ultimate

This blog aims to address all aspects of DSL development, focussing particularly on DSLs embedded in Ruby.

If our DSL department isn't enough for you, you might want to check out this newcomer.

While you wait to see how this blog turns out, you might want to browse our DSL archive: here and here (we also have a fairly empty Ruby department, by the way). After all, we've been doing this for nearly six years now!

Welcome to blogosphere, Dave & Tobias!

Ralf Lämmel and Erik Meijer. Revealing the X/O impedance mismatch.

When engaging in X/O mapping, i.e., when viewing XML data as objects or vice versa, one faces various conceptual and technical challenges -- they may be collectively referred to as the `X/O impedance mismatch'. There are these groups of challenges. (i) The XML data model and the object data model differ considerably. (ii) The native XML programming model differs from the normal OO programming model. (iii) The typical type systems for XML and objects differ considerably, too. (iv) Some of the differences between data models and between type systems are more like idiosyncrasies on the XML site that put additional burden on any X/O mapping effort. (v) In some cases, one could ask for slightly more, not necessarily XML-biased language expressiveness that would improve X/O mapping results or simplify efforts.

The present article systematically investigates the mismatch in depth. It identifies and categorizes the various challenges. Known mitigation techniques are documented and assessed; several original techniques are proposed. The article is somewhat biased in that it focuses on XML Schema as the XML type system of choice and on C# as the OO programming language of choice. In fact, XSD and C# are covered quite deeply. Hence, the present article qualifies as a language tutorial of `the other kind'.

This paper is over 100 pages, way longer than I have the time to read at the moment. Skimming, the paper looks interesting and useful. If you manage to read the whole thing, do share your observations with us in the discussion group.

The title says it all. Asynchronious messages are a very nice solution when you're sending a command (send it and forget it, as opposed to twice the time required waiting for a response). But what about querying for information? In this case you're forced to fake synchronious messanging by maintaining information about your request (either in a hashmap, or in a message itself). Of course continuations are also a nice solution for faking synchronious messages.

It's pretty easy to see how message passing and special scheduling are great paradigms for the type of problems that Erlang was designed to solve. Not so easy for asynchronious messages, though. Can anyone comment on why Erlang designers went with asynchronious messanging? Is it because it's a more general feature and synchronious messages can be implemented on top of them?