[clean-list] Help on implementation of interactive local state transition syst ems in Clean...

[Peter Achten]

At 18:25 12-6-01 +0200, Fabien Todescato wrote:

>[...] I
>have dived into Dr. Peter Achten and Pr. Rinus Plasmeijer article 'The
>implementation of interactive local state transition systems in Clean'.
>[...] I am still stuck on the crucial use of lazy evaluation in the
>function nextstate - section 2.2 local state transition systems -.
>[...]
>I have the vague intuition that this technique is required to have a correct
>behavior of the state transition system in case a local state transition
>function of some object causes - directly or indirectly - the application of
>other state transition functions to the same object. Indeed, I experienced
>putting a strict #! instead of the lazy # in the call back function of some
>interactive object causing indirectly state transitions on the same object,
>and got a splendid "Cycle in spine" error when the call back was
>evaluated...
>
>This is, however, not clear at all to me, I have troubles visualizing
>correctly the mechanism, and I would be grateful to anyone providing me with
>further explanations.

A state transition function, f say, must compute a 'new' state value given 
an 'old' state value.
A state value is always a pair of:
   * a collection of local state values, and
   * the whole state transition system ((LSTS s) in the paper, (PSt s) in 
the Object I/O library)

When f is evaluated, the collection of local state values are simply 
references to these values as found in the whole state transition system. 
In the whole state transition system argument all references to these local 
state values have been replaced by lazy forward references to the new local 
state values (that are to be computed by f).

So, only if f relies on the new local state values (that it is about to 
compute), then indeed a cycle-in-spine is created. The only source of 
creating such a cyclic dependency in the Object I/O library is by using the 
synchronous message passing functions in StdReceiver because this will 
cause the evaluation of the receiver function; if it depends on (part of) 
the same local state values as f then a cycle-in-spine occurs. It can also 
occur if a function is annotated more strictly than necessary, but I can't 
give you a general rule when to safely add strictness annotations.

In the Advanced Programming course we give at Nijmegen, I have tried to 
visualise what happens for an extremely simple example. You can see the 
PowerPoint slides of this lecture at:
         http://www.cs.kun.nl/~peter88/onderwijs/GP2000-2001/LSTS.ppt


>Speaking from my humble experience, one of the main problem with the
>acceptance of pure functional programming in the mainstream, is that the
>problem of the complexity of the state of medium-sized to large stateful
>applications is difficult to handle, a problem, however, that Object
>Oriented programming does address adequately. It seems that the design of
>the ObjectIO library provides an elegant solution to that problem in a true
>functional spirit, but unfortunately it is difficult to find documentation
>about that technique targeted to the average software engineer... I may
>suggest that an addendum to the otherwise excellent ObjectIO documentation
>may be welcome, that would emphasize the use of local state transition
>systems for structuring complex state in a set of loosely coupled stateful
>components, and not only from the GUI construction point of view, but from a
>general software engineering point of view.

I agree. Currently we are working on a new version of the Object I/O 
library. I intend to take the opportunity to add some chapters in the 
Tutorial about these subjects when we release the new version.

Regards,
Peter