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

[Michael Day]

> Hmm, that raises another problem: what about the singleton variables
> `StreamA1' and `StreamB1' in this example?  If these streams are I/O
> streams, whose updates have externally visible side effects, don't you
> need some way to tie those variables back into the final io__state
> returned from main?  Otherwise the compiler could just optimize away
> all the stuff in curlies, since it is det and has no output variables
> except the singletons, whose scope is local to that goal.

Time to split that pesky io__state again :)

:- open(stream::uo, io__state(T)::di, io__state(io__state(T))::uo) is det.

:- close(stream::di, io__state(io__state(T))::di, io__state(T)::uo) is det.

Now every open stream must be closed or there will be a compile error,
assuming io__state is parameterized by T and main looks like this:

:- pred main(io__state(T)::di, io__state(T)::uo) is whatever.

Alternatively if people don't like to change the definition of main, we
can define these:

:- begin_stream_stuff(io__state::di, io__funky_state(nil)::uo) is det.

:- end_stream_stuff(io__funky_state(nil)::di, io__state::uo) is det.

So you can call begin_stream_stuff to get a funky_state, then open streams
with that, and all streams must be closed before you can call
end_stream_stuff to get back your old io__state to return from main. I'd
prefer the former, though.

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