Lambda the Ultimate

Processor?

Looks something like the type of a query planner in a DBMS. They decompose queries in SQL say and produce a sequence of underlying database actions.

In the system I work on we have a highly-data-parallel DSL whose interpreter is written in this style so that it can execute the side-effects of e.g. 10000 "simultaneously" executing processes together in an efficient way (updating databases, sending SMS, etc). If we ever decide to rewrite the compiler for this language it will likely be extremely easy to Quickcheck the new against the old by comparing action-sets for random programs.

Generally speaking though I avoid programming in this style because of the trampolined-style-esque awkwardness. I wonder if e.g. the Monad crowd have clever ideas for "capturing" the would-be side-effects of a program without immediately executing them?

Looks very much like an Actor to me:

An actor is a computational entity that, in response to a message it receives, can concurrently:

• send a finite number of messages to other actors;
• create a finite number of new actors;
• designate the behavior to be used for the next message it receives.

Of course, the approach you are asking about doesn't (explicitly at least) involve creating new actors. But the ExternalCommands sound a lot like sending messages to other actors, and the way an actor designates a new behavior for the next message would be the same as designating a new State for acting on the next command. The quote above is from an article about the Actor model. Equivalent notions can be found in the various process calculi, such as the pi-calculus or CSP, where the entities are referred to as "Agents" or "Processes".

As a rather nitpicky aside, what you're asking about isn't really a "design pattern" in the technical sense, since it describes neither the specific type problem being solved (beyond "implementing module behavior"), or the forces within the problem context that are resolved by the solution, but only a solution by itself.

So, it is not Actor model, it can be used as a low-level layer to implement operations of actors.

I asked about it, because some guys I know are advocating structuring programs in that way, and they named it "Nianio" pattern. There is an informal overview of Nianio out there on the web, along with some examples of contexts and problems where it could be applied, but unfortunately it is in Polish language.

So I was curious to what extent are they re-inventing the wheel.