[m-dev.] stream typeclasses (again)

[Julien Fischer]

On Sun, 19 Mar 2006, Ian MacLarty wrote:

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

I meant with respect to the state that is updated - I know it differs
with the Unit argument.

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

Ok.  I'll take a look at it in the next couple of days (if you don't
get there before me).  BTW, I've almost finished a change that fixes
the problems with file streams in the io module overlapping when used
in typeclass instances.

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