Lambda the Ultimate

On Wednesday October 19, 2005, Mads Torgersen, Amanda Silver, and yours truly will be presenting a BOF on LINQ in the Royal Palm Salon 1+2, 5:00 – 7:30pm during OOPSLA 2005 in the Town & Country Resort & Convention Center in San Diego, CA.

With three language geeks (one from VB land, one ex-academic from the Java side, and one ex-academic from the Haskell side) presenting, this should be a fun night.

Abstract
Modern applications operate on data in several different forms: Relational tables, XML documents, and in-memory objects. Each of these domains can have profound differences in semantics, data types, and capabilities, and much of the complexity in today's applications is the result of these mismatches. The future "Orcas" release of Visual Studio aims to unify the programming models through integrated query capabilities in C# and Visual Basic, a strongly typed data access framework, and an innovative API for manipulating and querying XML. This talk explains the ideas behind language integrated queries (LINQ) and discusses the language enhancements behind them.

Slides The slides for the presentation are here.

Territorial Exception Handling, Marco Kesseler, February 12 2004

(Exceptions are still something I think the programming community hasn't really nailed down. For every person that says they are evil, another says they are salvation. Some folks suggest looking for a middle path.)

Hacle: "Can the Clean compiler, in combination with this tool, produce faster executables than existing Haskell compilers?" ... "These results show two cases where the Hacle then Clean compilation system produces faster executables than the GHC compiler. Likewise they also show two cases where the opposite is true. So, since the Hacle then Clean compilation system is potentially beneficial, its completeness is now of importance."

I'm developing a three-phase semantics for a block diagram language. I'm calling the first two phases "translational" and the last phase "denotational." This distinction between "translational" and "denotational" feels right, but I'm not sure it is right and was hoping some LtU members might be able to help.

I'm using "translational" to describe the phases of the semantics that could also be called desugaring. The distinction I see between these phases and the final denotational phase is that the denotational phase cannot be captured as translation to a finite program in the target language. The target language is a lightly sugared lambda calculus or a very limited Haskell, depending on how you look at it. (Actually the latter interpretation is how I actually make this semantics executable. I mention this only because I think it is cool, not because I think it is relevant to the question at hand.)

This all seems to stem from the denotation for the "letrec" construct, which, via the fixed-point operator, involves potentially unbounded recursive calls to the meaning function.

In particular,

meaning [LETREC declarations IN body] env
=
meaning body (fix newEnv)
where
newEnv e' = updateEnv (meaning declarations e') env

and fix and updateEnv are as you might expect, and "meaning" is assumed to be overloaded to work on declarations as well as expressions.

Does this distinction between translational and denotational semantics seem correct? As such, would a denotational semantics of a language w/o letrec be translational? And would a denotational semantics of a language with letrec and with letrec in the target language be translational? Are all operational semantics translational?