[Haskell-cafe] Non-blocking for reactive programs (was: Objects in Haskell)

[Graham Klyne]

At 00:39 29/11/04 +0100, Benjamin Franksen wrote:
>One problem remains: to preserve reactivity, the programmer must make sure
>that methods don't execute IO actions that may block indefinitely.
>Unfortunately there is no way in Haskell to enforce this, because
>(indefinitely) blocking IO actions have the same type as non-blocking ones.
>Too late to change that, I guess...

I was somewhat intrigued by this comment.  Maybe I'm missing the point or 
simply too detached from the thrust of this thread to make any sense here, 
but wondered if anything really needs to be changed to be able to express 
this idea of non-blocking IO.

Suppose we define a new type, say NBIO, which, like IO, allows any 
interaction with the external world, but with the proviso that it never 
blocks (I shalln't attempt to try and define exactly what this means, but 
hope that the intent is clear).  A key function associated with this type 
would have type:
     forall a. NBIO a -> IO a

Thus any non-blocking I/O activity can be implemented in NBIO, and its 
IO-equivalent is always available.  But not the converse, of course.

...

I think I now see the problem:  while functions can be implemented in NBIO, 
and thereby convey an intended guarantee to the caller, there's no way I 
can see for the Haskell type system to stop a programmer to write a 
function of this type that actually uses (but does not return a value from) 
an IO value.  Without this, how can facilities like Debug.Trace be provided?

But then again, if no value from an IO is ever actually used or referenced 
outside the IO code, doesn't lazy evaluation mean that there's never any 
need to evaluate the value within IO?

Now getting hopelessly out of my depth, but interested in any comments you 
may have...

#g
--

>Btw, here is one of my all-time favourite quotes:
>
> >>>
>The view of indefinite blocking as a transparent operational property dates
>back to the era of batch-oriented computing, when interactivity was a term
>yet unheard of, and buffering operating systems had just become widely
>employed to relieve the programmer from the intricacies of synchronization
>with card-readers and line-printers. Procedure-oriented languages have
>followed this course ever since, by maintaining the abstraction that a
>program environment is essentially just a subroutine that can be expected to
>return a result whenever the program so demands. Selective method filtering
>is the object-oriented continuation of this tradition, now interpreted as
>``programmers are more interested in hiding the intricacies of method-call
>synchronization, than preserving the intuitive responsiveness of the object
>model''.
>
>Some tasks, like the standard bounded buffer, are arguably easier to 
>implement
>using selective disabling and queuing of method invocations. But this help is
>deceptive. For many clients that are themselves servers, the risk of becoming
>blocked on a request may be just as bad as being forced into using polling
>for synchronization, especially in a distributed setting that must take
>partial failures into account. Moreover, what to the naive object implementor
>might look like a protocol for imposing an order on method invocations, is
>really a mechanism for reordering the invocation-sequences that have actually
>occurred. In other words, servers for complicated interaction protocols
>become disproportionately easy to write using selective filtering, at the
>price of making the clients extremely sensitive to temporal restrictions that
>may be hard to express, and virtually impossible to enforce.
><<<
>
>(see http://www.cs.chalmers.se/~nordland/ohaskell/rationale.html)

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact