[MLton-user] simple, portable, asynchronous programming in SML

[Wesley W. Terpstra]

I liked the EVENT signature, but confess to not having read the  
implementation.

On Aug 1, 2006, at 2:51 AM, Stephen Weeks wrote:
> As another example, which one can already see in the code I sent,
> consider my implementation of multicast and compare it with the
> implementation that Reppy gives in section 5.5 of the CML book.  My
> implementation uses events, while Reppy's uses threads.  In the end,
> the implementations do very similar things, but I think it is arguable
> that my implementation is simpler, and shows that an appropriate
> combination of "when" and recursion nicely achieve the effect of a
> separate thread.  I'm not claiming any general result here -- simply
> that in more situations than I would have thought, non-preemptive
> threads aren't necessary and don't make things easier.

Am I missing something?
I don't see any conflict here at all.

What I see is that there is some underlying event loop (in pretty  
much any non-command-line program), which fires off events. Stephan's  
system is just a way of standardizing what those events are. If one  
wanted too, it would be easy (in MLton) to create a THREAD interface 
+structure which implemented a 'yieldUntil' function that waited for  
an event to be true. Then you get your non-preemptive threads and the  
callback system working together with a unified event type system.  
Seems like a good goal to me.

Taking this further, one could imagine doing something like the  
rewrite/port of state-threads.sourceforge.net to SML I did, but in a  
cleaner way. Simply add in an 'event table' of multicast events that  
are set on file descriptor readiness, and you can make auto-yielding  
variants of 'read' which these threads could use. Or, if no threads  
are required, just use closures, as Stephan says.