Lambda the Ultimate

I designed a language based on connections, objects, and FRP signals (not streams) as part of my dissertation. Here is a paper presented at this year's ECOOP about it.

Neat. This reminds me, somewhat, of Cocoa bindings. Useful stuff, always.

However, it doesn't seem anywhere near the same as what I am trying to do with Pipeline. ... I'll just have to make a more complete specification of the semantics and bring it up later.

[Edit] Has anybody noticed how the MVC paradigm always seems to work more smoothly when each component is implemented in its own DSL? SQL databases and adapters tend to work perfectly for models, SuperGlue/bindings for controllers, and nibs/templates for views? (I'm bringing up random examples from Java/SuperGlue, Objective-C/Cocoa, and Ruby/Rails environments here.)

Has anybody noticed how the MVC paradigm always seems to work more smoothly when each component is implemented in its own DSL? SQL databases and adapters tend to work perfectly for models, SuperGlue/bindings for controllers, and nibs/templates for views?

That is because programming languages force multiple values into an array or a stream, while DSLs often abstract multiple values away so you can treat them as one value. You don't need a loop in SQL or XPath. I'm toying with that idea in my toy programming language Moiell, so that you can f.e. write quicksort like this:

?QSort :: ?first, ?rest => 
  QSort(rest < first)
  first
  QSort(rest >= first)

Just like most DSLs, programming this way tends to let you program closer to normal speach, i.e. QSort(rest < first) for "quicksort the rest smaller than the first".

Pipelines can also play a mayor role in mainstream PLs where one might create architectural design pattern using them. My prime example is C#. Here a Connect attribute is defined which is parametrized with "in" and "out" and which can be annotated to properties:

[Connect("in")]
bool hasUserPin
{
    get{ return _PIN }
    set{ _PIN = value}
}

This property is defined in an arbitrary class A that is derived from the base Connectable. If an instance of A is created the reflective framework ( via a construtor call of Connectable ) seeks for a property with the same name and type as hasUserPin but equipped with a [Connect("out")] attribute and sets the value of the in-connected property with that of the out-connected property.
The process requires a living object b of a class B that defines the out-connected property. If not yet available it might just be created; some method defined by Connectable e.g. execute() will be applied and the value of hasUserPin in B will finally be feeded into the in-connected hasUserPin property of A. The classes A and B don't need to know each other i.e. A does not need to hold an instance of B or vice versa. It is only the reflective infrastruture that couples A and B but it also doesn't know about A and B explicitely.

Judging by description, the "Connectable" approach is similar to Seam bijection.
And, of course, to Qt's Signals and Slots.

This paper of mine, to be presented in August, explains a design of a small embedded language, hosted in OmniMark. You might find it interesting. The language is data-driven and contains conditionals and various loop-building combinators. Since the venue is Extreme Markup 2006, the primitive components shown in the paper are oriented towards XML processing, but the same combinators (i.e., language constructs) could be used in many other domains.

I'm thinking about reimplementing the same thing in Haskell and applying it to the shell-scripting domain.