Platform Strategy & Architecture
« Metaprogramming: Open Sourcing CanappiMetaprogramming: Revisiting Barbara Liskov's Assumptions »

Programming with Abstract State Types

  05/20/13 04:08, by jdubray, Categories: MDE, SOA, Xtext, MOP, UML

I'd be the first one to recognize that I am playing way out of my league here, no question about it, but it seems to me that Computer Science has been neglecting, if not abusing, the notion of state in ways that seem to be counter productive. I understand that the work of Church and Turing was all about "Computing" and not surprisingly when we started to look for better abstractions to write programs the foundation of λ-calculus was never reassessed but it is difficult today to not ask the question as to whether Abstract Data Types are at the foundation of the General Theory of Software Engineering (GTSE).

I spent the last couple of weeks pounding on the idea that there is more to Barbara Liskov statement about the fundamental role of programs than Abstract Data Types

I believe that the fundamental role of programs is to modify state not just the bits

Indeed, when you look at it closely, the role of "computers" today is far less about "computing" than it is about managing state, even though computing is required to transition from state to state properly.

After defining BOLT, and looking at extensions in the problem domain, I found that the idea of defining a programming model based on Abstract State Types could shed some new light on what a programming language truly is.

Surprisingly, there is very little literature about ASTs as I define them. It seems that ASTs fit the model of Coalgebras, but again, I am playing way out of my league here. 

In the paper referenced below, I define an AST as a simple data structure (key value pairs) which all share the same lifecycle (yes, states have a lifecycle too!). A state lifecycle is triggered by an interaction between two (or more) states. States are immutable and new states (of the same type or a different type) are created at the end of an interaction. I define 3 composition mechanisms (containment, extension, connection). Interestingly, there is no ASM (Abstract State Machine) behind ASTs. What we see as a "State Machine" is actually the occurence of repeatable interactions, so all the complexity associated to modeling state machines goes away.

If anyone feels there is a strong analogy between ASTs and QED, well, it is nearly by design, but it really came about from me staring at UML State Diagrams, linking them to business process execution, then to business strategy and then all the way back to problem definition and today programming model. 

This paper is far from complete, a very rough draft at best. I publish it as is for three reasons:

a) I strongly believe that the fundamental idea behind ASTs will not change

b) It would take me an infinite amount of time, which I don't have, to bring it to maturation

c) This is really a call for help, if someone would like to jump in as a coauthor, to further the idea

I don't see ASTs as being the next gen programming concept, ... well who knows, but it was hard to resist not extending the BOLT conceptual framework to the programming model level, especially in the context of Barbara Liskov's statement on the role of programs.

Here is the paper, as usual any feedback is welcomed, especially if someone has already worked on that idea. My next step is really to put this idea in practice to explore it further. In particular the paper does not speak at all of the general orchestration behind state interactions (mechanisms such as addressing, activation, ...) but this is by design because I feel it is totally orthogonal.

Again, I welcome the contribution of one or two co-authors, otherwise I'll continue working on this paper in an open content mode.

No feedback yet




My views on SOA

I work at

Recent projects

the old ebpml

powered by b2evolution free blog software

©2018 by Jean-Jacques Dubray

Contact | Help | b2evolution skins by Asevo | blog software | best hosting