Home » forums » LtU Forum

How do you call such a design pattern

I wonder how you would name a design pattern, where you implement a "module" behaviour by function of the following form

f : State x Command -> State x (array of ExternalCommand)

or (equivalently)

f : State x Command x ([] -> ExternalCommand) -> State

where
- State, Command, and ExternalCommand are purely data (no resources nor functions)
- ExternalCommand is likely to describe operations on (external) resources
- in the second form, ExternalCommand-s should be processed after evaluating f (they could be queued externally)

By Marcin Stefaniak at 2007-02-23 17:12 | LtU Forum | previous forum topic | next forum topic | other blogs | 5686 reads

Comment viewing options

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

Processor?

Processor?

By hutorny at Fri, 2007-03-09 16:23 | login or register to post comments

Planner?

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.

By Daniel Slaney at Sat, 2007-03-10 01:26 | login or register to post comments

Tangentially

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?

By Luke Gorrie at Sat, 2007-03-10 13:43 | login or register to post comments

The Awkward Squad paper

Doesn't this paper provide a clue? IIRC, they build a description of the I/O as a trace of sorts, which lets them reason about the side-effects without having performed them.

By naasking at Sat, 2007-03-10 19:50 | login or register to post comments

Actor?

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.

By Allan McInnes at Sat, 2007-03-10 21:52 | login or register to post comments

Thank you

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.

By Marcin Stefaniak at Wed, 2007-03-21 10:54 | login or register to post comments