[m-dev.] streams proposal (part 2)

[Julien Fischer]

On Fri, 24 Feb 2006, Ian MacLarty wrote:

> > %-----------------------------------------------------------------------------%
> > %
> > % Stream errors
> > %
> >
> > :- type stream.name == string.
> >
> > :- type stream.result(T)
> >     --->    ok(T)
> >     ;       eof
> >     ;       some [Error] error(Error) => stream.error(Error).
> >
> > :- typeclass stream.error(Error) where
> > [
> >     % Convert a stream error into a human-readable format.
> >     % e.g. for use in error messages.
> >     %
> >     func error_message(Error) = string
> > ].
> >
>
> I don't think this is a particularly useful way to do errors.  In my opinion
> it would be better to add an extra Error argument to the stream typeclass and
> make Error functionally dependent on Stream.  That way you can do more
> with a returned error than simply converting it to a string (since you'll
> know its ground type).

Certainly you can make it part the typeclass.  At the time I wrote that
I wasn't sure the extra complication was worth it.

> > %-----------------------------------------------------------------------------%
> > %
> > % Streams
> > %
> >
> >     % The root of the stream class hierarchy.
> >     %
> > :- typeclass stream(Stream, State)
> >     <= (Stream -> State) where [
> >
> >     % A human readable name describing the stream.
> >     %
> >     pred name(Stream::in, stream.name::out, State::di, State::uo) is det,
> >
>
> I would prefer this to be
>
>     func name(Stream) = string,
>
> but for the moment it has to have the State, because io.input_stream needs to
> read the I/O state to access the stream info database.
>
> >     % Close the stream.
> >     % Throws an exception if there is an error while closing the stream.
> >     %
> >     pred close(Stream::in, State::di, State::uo) is det
> > ].
> >
>
> I don't think close should be a method of the typeclass.  I think different
> stream types may require different close methods (with different numbers
> and/or types of arguments) or no close method at all.

Can you provide an example?

> Typically the operations of opening a stream and closing
> a stream will go together and since we are not including opening of
> streams in the typeclass I don't think we should include closing of
> streams either.

Yes, but that's because (under this model at least) you need an already
open stream to invoke the typeclass methods upon - I don't see why
close shouldn't be a typeclass method

> > :- typeclass stream.putback(Stream, Unit, State)
> >         <= stream.input(Stream, Unit, State) where [
> >
> >     pred unget(Stream::in, Unit::in, State::di, State::uo) is det
> > ].
> >
>
> How would unget work?  What happens if I get an 'a', but then unget a 'b'?

It would work like ungetc() does in C.  So if you get an 'a' and then unget
a 'b', then the next thing you get will be a 'b'.

> One possible problem with the proposal is you can't have the notion of a
> current open stream (like we do in io.m).  This is because you can't get
> enough information from the stream alone to know what typeclass it
> belongs to (you need the unit type too), so you can't store the stream
> value in, say, a global mutable and then later extract it and use it.

That has little to do with the actual streams proposal - we could always
extend the Mercury system to have a notion of a current stream if that turns
out to be a useful thing to do.

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