[m-dev.] stream typeclasses (again)

[Julien Fischer]

On Sun, 19 Mar 2006, Ian MacLarty wrote:

> On Wed, Mar 08, 2006 at 03:03:52PM +1100, Julien Fischer wrote:
> >
> > Are you reasonably satisified with the rest of the design as it stands?
> >
>
> Not really.  I'm a bit dissapointed I couldn't implement the rot13
> example the way I wanted, because of the current restrictions on
> instance declarations.  It seems that making the state and the stream
> arguments polymorphic is going to be more trouble than it's worth (at
> least with the current type and mode systems).
>
> What do you think about doing one of the following:
>
> 1. Make the state updated by a stream always be io.state.  The only
>    example I could think of where it wouldn't be an io.state is with
>    string buffers, but then you showed it's probably better to use the
>    io.state anyway.

That's pretty much what extras/streams does now.

> 2. Do away with the Stream argument and just have a di, uo pair of polymorphic
>    states.  Something like:
>
> 	:- typeclass stream.input(Unit, State) where [
>    		pred get(Unit::out, State::di, State::uo) is det
> 	].
>
>    File streams could be implemented by embedding the IO state, together
>    with the file handle and name in the State type.
>
>    We'd also then be able to define forwarding streams like my version
>    of rot13 nicely:
>
> 	:- type encryption_stream_state(S)
> 		--->	encryption_stream_state(
> 				stream_state_to_forward_to	:: S,
> 				internal_encryption_state 	:: ...
> 			).
>
> 	:- instance stream.output(string, encryption_stream_state(S)).
>
>   This instance declaration conforms to the current restrictions.
>
>   With such a scheme we could also ensure that closed streams are never
>   used, by clobbering the stream when it's closed.
>
>   Do you think the mode system is up to the task?  I don't see why it
>   wouldn't be, since it handles di, uo pairs for IO just fine.

I think that embedding the I/O state inside anything tends to lead to
highly confusing code; it's something I would prefer to avoid.

Julien.

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