[m-dev.] Stream2000

[Fergus Henderson]

On 15-Nov-2000, Michael Day <mikeday at corplink.com.au> wrote:
> 
> > I have switched over to using abstract types.
> 
> Must the stream predicates read_char and write_char be threaded with an
> io__state rather than the stream itself?

They don't *have* to be, but that's the simplest approach.

As I wrote earlier, there are several different possible approaches:

 | It depends on what you're trying to achieve. That [Peter's proposal]
 | is a less ambitious design, more similar to the existing I/O
 | library; it just adds the possibility of user-defined stream types
 | (at the Mercury level) and provides genericity over the different
 | stream types.  The other alternatives that we're discussing are
 | more radical changes: by splitting the io__state into sub-states
 | for different streams, they allow more parallelism/concurrency, and
 | are arguably a more elegant design, but this comes at a cost of
 | increased complexity (e.g. the need to lock files, for the
 | deterministic parallelism case, or the unspecified order of
 | side effects, for the `cc_multi' concurrent case.).
 | 
 | These approaches don't have to be mutually exclusive, of course.
 | There may be a case for providing all three:
 |         - one to use when you care about the order of side effects
 |         - one to use when you don't care about the order of side
 |           effects, even though they may influence the result
 |         - one to use when you know that the order of side effects
 |           won't influence the result

Pete's current proposal addresses the first of these three,
and (with io__fork or io__split) can also be used to address
the second.  It doesn't address the third.  But let's do it
one step at a time, and leave the third approach for a later
change.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------