Sorry for the delay -- I've been away for a week, without good network connections... > In regard to asynchronous I/O, you said: > > > This applies equally to the request model. Nothing prevents the submission > > (but not necessarily resolution) of a later I/O request during resolution > > of an earlier request if those requests are independent (and the request > > stream is hyper-strict). > > to which I replied: > > | Isn't the resolution of an I/O request essential? If we cannot get the > | result of an I/O request out of the response stream, does that not indicate > | that the stream model is inadequate for allowing the kind of parallelism I > | mentioned? > > Nigel asked me what I was getting at here, so I suppose other people are > wondering too. I would suggest that parallelism is a red herring (with regard > to streams vs. continuations). I concur. The two models seem to have the same opportunities for parallelism as far as I can see. > The real issue is polymorphism. > > (In my reply above I was thinking of polymorphic, asynchronous I/O requests). > > A stream model (in a statically typed language at least) will never be able to > guarantee type safety when extracting the result of a polymorphic request. That's certainly an acknowledged shortcoming of the request model. > Thus I suggest that we do away with the stream model altogether. But that's quite a leap from your previous statement. Personally I like the continuation style (though I prefer monad style, since it's more open to transformation), so I'll leave it to others to defend streams... The usual justification for having streams is, of course, that continuations can be coded efficiently using simple streams, but not vice-versa (some form of assignment is necessary to avoid quadratic complexity when constructing the request stream if continuations are to be the primitive sort of IO). > Kevin, why should the request stream be hyper-strict? That's a sufficient condition to ensure the independence of the requests, and avoid difficulties with requests whose value is _|_. But it's a stricter than necessary condition. Kevin
