Lambda the Ultimate

I've been spinning my wheels on this for awhile, so I'm hoping LtU has an answer: has there been any connection derived between transactions and promises/logic variables? I'm considering here promises as implemented in Alice ML and at least ACI properties of transactions minus the D. The connection is more apparent in a personal project where this came up, so apologies if this seems ridiculous at first.

If you view the store as an immutable pair:

type 'a Store = { current: 'a; future: 'a Store Future }

beginning a transaction consists of starting a computation with the promise for that future:

val begin_trans: 'a Store -> ('a Store Promise -> ()) -> ()

and committing a transaction consists of resolving the promise for that future

val commit_trans: 'a Store Promise -> 'a Store -> ()

Of course, transactions can nest stack-like, and one could recreate this by creating more promises down the call chain which get resolved as calls return. Of course, promises also permit non-nested resolution if needed (though I'm sure that sounds ridiculous for transactions).

It seems a little tenuous as I've glossed over many details and LtU isn't the place for detail design discussions, but hopefully it's understandable enough that someone can point out where this has been already been discussed, or tell me how ludicrous the entire idea is.

Mitchel Resnick, John Maloney, Andrés Monroy Hernández, Natalie Rusk, Evelyn Eastmond, Karen Brennan, Amon Millner, Eric Rosenbaum, Jay Silver, Brian Silverman, Yasmin Kafai, Scratch: Programming for All, Communications of the ACM, vol. 52, no. 11, November 2009.

When Moshe Vardi, Editor-in-Chief of CACM, invited us to submit an article about
Scratch, he shared the story of how he learned about Scratch:

A couple of days ago, a colleague of mine (CS faculty) told me how she tried to
get her 10-year-old daughter interested in programming, and the only thing that
appealed to her daughter (hugely) was Scratch.

That’s what we were hoping for when we set out to develop Scratch six years ago. We
wanted to develop an approach to programming that would appeal to people who hadn’t
previously imagined themselves as programmers. We wanted to make it easy for
everyone, of all ages, backgrounds, and interests, to program their own interactive stories,
games, animations, and simulations – and to share their creations with one another.

Scratch is the cover story of the November 2009 issue of CACM. The goal of Scratch is to get kids programming so that they become more fluent in information technology, and develop "computational thinking" skills. Scratch is a graphical language based on a collection of “programming blocks” that children snap together like Lego blocks to create programs. The programs themselves appear to be imperative in nature (at least based on the samples in the CACM article). Programs can be made concurrent by creating multiple stacks of blocks, and the authors claim that their goal is to make concurrent execution as intuitive as parallel execution.

Scratch was previously mentioned on LtU here.

I haven't heard anyone mention it in the forums yet, so I figured I'd provide a pointer.

Rx is a .NET Library that allows programmers to write succinct declarative code to orchestrate and coordinate asynchronous and event-based programs based on familiar .NET idioms and patterns.

The Rx library provides APIs to create instances of these interfaces from scratch, convert existing asynchronous patterns such as events to these interfaces, query, transform and merge observables.

In the recent past there have been several videos on Channel9 talking about Rx in Depth. We can strongly recommend watching them:

• Kim Hamilton and Wes Dyer: Inside .NET Rx and IObservable/IObserver in the BCL (VS 2010)
• Expert to Expert: Brian Beckman and Erik Meijer - Inside the .NET Reactive Framework (Rx)
• E2E: Erik Meijer and Wes Dyer - Reactive Framework (Rx) Under the Hood 1 of 2
• E2E: Erik Meijer and Wes Dyer - Reactive Framework (Rx) Under the Hood 2 of 2

I particularly recommend the two-part video with Erik and Wes, which provide the most LtU-relevant content.

Presuming for now that a "module" 1) is a named and managed name space; 2) is a body of definitions, some of which are private and others provided for export to other modules; 3) is also a compilation unit; 4) is, in fact, imported by other modules, with circularity of imports forbidden or permitted based on the language definition; 5) is compiled separately and linked into a standalone "executable program" file; 6) may be a privileged module in an "executable program" linking activity as the "main" module containing either a function that begins program execution or a series of sequential definitions (or "statements") that essentially comprise an equivalent "main" function that begins program execution.

I think that's all grammatical, and in fact, more or less common policy for many programming languages with oodles of variations on this basic theme.

I seek papers that discuss (1) module initialization, such as a variable definition in a module that requires on it's "right hand side" a complex computation, 2) perhaps a computation that requires definitions from other modules, 3) the compile time determination of the "loading" or "initialization" of modules, 4) the wisdom or lack thereof of only allowing function definitions in modules, perhaps with only a special "initialization" section of the module definition (Modula 2, Turbo Pascal...); 5) policies regarding the permission or forbidding of circular module imports.

So I'm looking for the "finest available wisdom" about some fairly prosaic issues surrounding a few aspects - modules, initialization, ordering, separate compilation, etc. - of programming languages designed for static analysis and program compilation. Did anyone "get it just right?" Or has anyone layed out the essential and unavoidable design trade offs showing that "getting it right" is a matter of programming language design 1) taste or 2) intended purpose or 3) implementation complexity or 4) etc. - you get the idea.

I do prefer papers a *little* "closer to the run time," as it were. I happen to suffer the somewhat common "too many pages of Greek symbols shuts down my brain" syndrome :-)

Any and all help and pointers greatly appreciated.

Scott