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

[Julien Fischer]

On Sat, 25 Feb 2006, Ian MacLarty wrote:

> On 24 Feb 2006, at 03:05, Julien Fischer wrote:
> >>
> >>
> >>>     % 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?
> >
>
> Well suppose I have a stream that encrypts data and forwards it on
> to some other stream.  Does having a close method for such a stream
> make sense?

It makes sense if you want closing the encryption stream to force the forwardee
stream to close as well.

> You don't want the close method for the encryption stream to close the
> stream it's writing to, since you may want to write some more unencrypted
> data to that stream after writing the encrypted data.

Ideally, we should be able to do both - leaving the close method out of
the typeclass makes it more difficult to do one of them and IMO just
reduces the expressivity of the stream typeclass.

> Another example:
> Suppose you have a stream for some network protocol that requires that the
> host that's closing the connection send the other host some kind of token to
> say why the connection is being closed.  This would require the close
> predicate to have an extra argument.  (You could also write the token before
> calling close, but it'd be a better design to give close an extra argument
> to be sure the required token is always written before closing).

I agree that's a complication and I (now) think that including the close
method where it currently is not correct (I've been implementing string
buffers as streams and closing them doesn't really make a great deal of
sense).  Perhaps we need a finer distinction between those streams
where some sort of close operation makes sense and those where it
doesn't.

My original motivation for including close was that it would make it
easier for code that uses streams to close the streams in an orderly
fashion if something goes wrong.

> >> 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
> >
>
> I think having a close method will also create confusion about who is
> supposed to close an opened stream.  How do I know a call to some
> predicate that accepts a stream argument will not close the stream?

Well, you could document your code ;-)  That particular confusion exists
anyway with file I/O as it is now anyway: whose responsibility is to
close open files?

Anyway, I've played around with this a bit more and I'll post a new
version of the stream typeclass soon.

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