Lambda the Ultimate

Hi there,

I promise this isn't a homework assignment of some sort, but it sure feels like it should be....

I'm working on a pet language of mine, which I'm building up from a hopefully minimal intermediate language very similar to lambda-calculus. In order to map proper (potentially mutual) tail-recursion onto the lower-level implementation mechanics, I realized that I need to be able to do the moral equivalent of a letrec, but, since this's just a kernel-intermediate language, I want to avoid syntactic sugaring until higher-level intermediate forms instead, and would strongly prefer to not introduce a one-off level of complexity to hack this up. Doing "let" with lambdas is trivial enough that even I understand it, but I've gone 'round the proverbial mulberry bush with letrec, and to no avail.

Would someone either have a quick answer as to how this's done, or else know of a link to a site/paper/discussion where folks do this? This really can't be as hard as it seems....

Thanks!

Interesting Job notice on SEWORLD, the Software Engineering email list:

Excerpt:
This project aims at building an extensible workbench for automated program analyses of embedded software. The workbench will combine a number of static analyses and coordinate them using an evidence manager. Different program analyses will feed into each other. Their results will be presented to the software developer in a simple, uniform way, via a plugin for an IDE (Visual Studio). The plugin and the analyses will be written in Scala, and Scala is also the primary implementation language for which analyses should be constructed.

Project link:
TRESOR : EPFL Thrust in Reliable Software Research

(Disclaimer: I no connection with any of these groups, whatsoever. It just looked interesting.)

This post is marginally on topic, touching social and economical sides of language design.

Recently I discovered to myself that orders for stock exchanges are little programs written in little language.
The concept of an exchange can be seen as an extension of the concept of money - while money relieves parties from necessity of finding right resources in right quantity to perform barter trade, exchange relieves parties from necessity of finding each other.
This is achieved by delegation of parties' decisions to smart (or not so) agents - usually called orders.

Orders historically started out as very simple agents - like "buy X units of Y for Z$". These agents would then be executed by exchange (in this simplest case, matching equal buys with sells).
With time, the DSL started to grow: "buy exactly X1 units of Y1 for up to Z$ by date D1 or else, buy up to X2 units of Y2 for the prevalent market price of date D2 but only if the prevalent market price of Y3 changed below Z3$ since the order was placed".

I found it very intriguing that exchange orders are not (usually publicly) presented as programs.
This may explain lack of attention from language design folks.
This again may explain why orders' DSLs are so ad hoc - though I certainly recognize there are a lot of other reasons, organizational and technical.
Another intriguing thing is that a lot of people placing their orders are not aware of exact rules for "order matching" (operational semantics of these DSLs). "It is performed by _the system_, why should I care about these details?"

Could it be that one venue to educate general public about languages and semantics is via articles about stock exchanges? :)

So the question: is anyone aware of any research for "better" orders language and/or "better" execution semantics for them ("better" being any of more intuitive/efficient/expressive/transparent)?