[m-dev.] std.io.state

[Fergus Henderson]

On 22-Aug-2000, Michael Day <mcda at students.cs.mu.oz.au> wrote:
> 
> Would it be possible to define io.state in the future standard library as
> follows:
> 
> :- type io.state(T) ---> state(c_pointer).
>
> To allow it to be split, using the type system to ensure that it is
> combined before main returns?

In theory yes, but in practice I don't think it would be a good idea,
because doing so would complicate the types, even for programs which
don't do any splitting or merging.  It would also cause backwards
compatibility problems.

> For example:
> 
> :- pred main(io.state(T)::di, io.state(T)::uo).
> 
> :- pred split(something::uo, io.state(T)::di, io.state(io.state(T))::uo).
> 
> :- pred merge(something::di, io.state(io.state(T))::di, io.state(T)::uo).
> 
> In which something is split off from the io.state, manipulated and later
> merged back in.
> 
> This would require changing the type of main, but is still backwards
> compatible, as creating a new std.io does not count as modifying the
> current io module.

Another alternative would be to provide both io__state/0 and
also io__state/1, and to make both of those instances of a type class.
This would ensure that programs which don't do any splitting or
merging can just use the simpler types.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- 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
--------------------------------------------------------------------------