[erlang-questions] Ideas for a new Erlang

[John-Olof Bauner]

Ulf Wiger skrev:
> 2008/8/1 Sven-Olof Nystr|m <svenolof@REDACTED>:
>   
>> Ulf Wiger writes:
>>  > > Ulf Wiger writes:
>>
>>     
>
>
>   
>>  2) One of the problem you are discussing is how to describe
>>    concurrent activities within one state machine. UML's mechanism
>>    for expressing composite state seems to be close to what is
>>    needed here.
>>     
>
> Not as far as I understand them. The composite state machines allow
> you to build very complex receive logic, but the message reception
> semantics is still FIFO, run-to-completion.
>
> There is, however, an attribute in UML - 'deferrable event', which allows
> you to specify that an event should be buffered, rather than discarded,
> if there is no matching handler in the current state. Not all UML-based
> tools support this attribute, and it receives very little attention in the
> specification.
>
> The key issue is that if you collect messages from different senders in
> a single mailbox or message queue, there will be accidental ordering.
> If your program logic strictly handles messages FIFO, it imposes a
> requirement that you have to be able to deal with all possible
> serializations of events - which invariably means that you have to
> perform some form of buffering in your application.
>
> Buffering channels address this problem, of course.
> The reason why I suggested that you look at the POTS example
> wasn't that I didn't think you could solve it with channels; it was
> to give you an *interesting* example in order to assess whether
> a channel-based solution would be more or less elegant than the
> traditional erlang version.
>
>
>   
RoseRT has defer/recall(All) and you can make recall on a port or all. 
You can choose if you recall from the front. We have a very complex 
state machine in this technology and it would be very interesting to see 
how it could be simplified in alternative technology which would be a 
very good thesis project.

BR
J-O