Home » forums » LtU Forum

Gilad Bracha on "Atomic Install"

Atomic Install from Bracha's blog.

I'm happy to see people talking about this, mostly because it's a pet topic of mine. I think too much ink has been spilled trying to shoehorn "dynamic languages" (by which I mean the usual suspects: Smalltalk-esque, mostly, and Python, PHP, etc.) into the vocabulary and mindset of type theory. Meanwhile, the operational model of these languages is really fundamentally different, and they are mostly quite similar: the semantics defines some run-time data model for programs, and then the program updates that model, usually in a fairly straightforward procedural way. In this sense, most of these languages can really be viewed as data description languages in disguise. Ruby is a great example of this: all of it's OO constructs are best viewed as syntactic sugar (semantic sugar?) over a fairly simple set of hashtable updates.

(Of course, the runtime data model may be abstract, as in JIT compiled code, and the runtime may not need to actually build and maintain it in a naive way, but that's hidden from the programmer.)

Anyway, given the above, it has for a long time struck me that a better direction for providing safety and static checking in such languages may be to borrow techniques from transaction processing. One might define suitable notions of data consistency and then insist that at particular semantic checkpoints, those consistency properties are guaranteed to hold. Atomic install is exactly what one such a mechanism might look like.

Is there work in the PL literature on this topic?

By Matt Hellige at 2009-11-02 23:47 | LtU Forum | previous forum topic | next forum topic | other blogs | 5015 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

In this sense, most of these

In this sense, most of these languages can really be viewed as data description languages in disguise.

If that were the case, then most of these dynamic languages would be more like Erlang and put a premium on fault tolerance and logic programming. Special emphasis would be put on proving the correctness of data schema evolution. It's not enough to simply evolve the schema, because in a distributed environment each node needs to know how to respond in the event of a schema change, even if that "how to" is some sneaky "failure oblivious" sleight of hand.

There is not much PL literature on this topic, although it did come up on the subtext mailing list a few months ago when somebody mentioned Squeak/Pharo Smalltalk's System.Editor module that extends the environment to allow for transactional upgrades. I would add that I often see bright programmers walk away from Haskell saying "types don't matter" (or something weird like that) because ultimately they wanted to express a problem like the one I mention.

[Edit: For the background on System.Editor: It came out of Colin Putney and Avy Bryant's Monticello DVCS project. Also out of that project is the configuration management API Metacello.]

By Z-Bo at Tue, 2009-11-03 00:25 | login or register to post comments

If that were the case, then

If that were the case, then most of these dynamic languages would be more like Erlang and put a premium on fault tolerance and logic programming.

Can you elaborate on how those requirements are intrinsically connected to what Matt Hellige calls a "data description language"?

By Kay Schluehr at Tue, 2009-11-03 06:04 | login or register to post comments