[m-dev.] stream typeclasses (again)

[Ian MacLarty]

On 3/19/06, Julien Fischer <juliensf at cs.mu.oz.au> wrote:
>
> 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.
>

No it isn't.  You still have the Unit argument which is the main
difference between this proposal and that one.  The Unit argument
allows you to write different types of things to the stream (strings,
chars, ints etc) without having to define seperate methods for each
type of thing you want to be able to write to (read from) the stream.

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

Ralph makes a good point too.  Let's go with the first approach, i.e:

:- typeclass input(Stream, Unit) where [
    pred get(Stream::in, Unit::out, io::di, io::uo) is det
].

etc.

Ian.

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