[m-dev.] for discussion: stream library v2

[Michael Day]

> If we're going to do that kind of thing, i.e. encoding the number of open
> streams as a type parameter to the io__state expressed in unary notation,
> then I'd rather we used a different type than `io__state' for the
> parameters, i.e.
...
> Even though there are more type names, I think this will make things
> less confusing, particularly when printing out types in the debugger
> and in compiler error messages.

Yes that would be nicer.

> Here I think it would be OK to just name `io__funky_state/1' as
> `io__state/1' and to use arity overloading to distinguish between
> io__state/0 and io__state/1.

Indeed :)

> We could even avoid the need for explicit calls to begin_stream_stuff
> and end_stream_stuff by defining `io__state' as
> 
> 	:- type io__state == io__state(io__nil).
> 
> However, any code using io__state/0 would be less reusable than it
> ought to be -- it could only be called on I/O states that have no open
> streams.  So although there would be some degree of backwards compatibility,
> this approach would still require sweeping changes to existing code if
> you want to make use of streams and interoperate with that existing code.

Right, I had some vague idea of io__state/0 being equivalent to
io__state(_), which isn't really possible. This doesn't sound too bad...

> However, I think there is a major flaw in all of these approaches:
> what happens with `try_io'?  When you throw an exception, you may skip
> an unknown number of calls to `close'.  The io__state at the end of
> try_io is unspecified, so skipping the calls to `close' doesn't
> cause any semantic problems, but the approach fails its intended goal
> of ensuring that every open stream is closed, so there's a serious
> practical problem.  The only way to avoid this problem would be
> to wrap the code between calls to `open' and `close' with an
> exception handler that called `close' and then rethrew the
> exception.
> 
> If you need to do that, then you might as well just provide a
> higher-order `with_stream' procedure rather than providing `open' and
> `close', so that programmers don't need to rewrite that exception
> handling code each time.  And once you do that, then you don't
> actually need the extra parameter to the io__state type.
> 
> 	:- pred with_stream(pred(stream(S)::di, stream(S)::uo),
>                 io__state::di, io__state::uo).

How would this predicate be used exactly?

Michael


--------------------------------------------------------------------------
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
--------------------------------------------------------------------------