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

Cool.  Let me know what changes you want me to do.  There's no point
us both making the same changes.  Once the new stream module has been
reviewed and committed I'll update term_to_xml.

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