[m-dev.] A bit lost, functionally, re: new stream proposal

[Julien Fischer]

On Tue, 28 Feb 2006 doug.auclair at logicaltypes.com wrote:

> >I've spent a bit more time playing around with the stream typeclass
> >proposal. Attached is the (or at least my) latest version plus a number of
> >example streams. (Ian, I think you mentioned you'd done some more work on
> >this as well?)
>
> (Ian, I'd also like to see your work as well).
>
> I'm glad to see you've include an (example) implementation of string_stream
> in buffer.m, but I'm a bit confused, functionally-speaking.
>
> I see streams in general tend to (but are not required to) depend on
> io.state.  Particularly, buffer.buffer, when it uses mutvars to track the
> state of the underlying string.

More generally, streams in this proposal are required to destructively update
some state each time you use them.  The tendency to use the I/O state in the
examples is, I suspect, just a matter of convenience.  Note that the orignal
Mercury streams proposal (in extras/streams) required the use of the I/O
state, so the current proposal is a bit more general.  (Whether the extra
generality is actually a useful thing remains to be seen.)

> I had seen something different for get/put operations on streams, more in the
> functional style of:
>
> get :: stream -> T -> stream
> put :: T -> stream -> stream
>
> So that, for example, put("huh?", !Stream) would update the (string) Stream,
> concatenating "huh?" to the underlying string.
>
> More generally, if io.state has nothing to do with a stream or its contents,
> how does one go about reading and updating streams using the proposed
> protocol?  Is State == Stream then?

Good question.  This was something that occurred to me while implementing the
buffer streams, however the current proposal doesn't really address that
situation and implementing the buffer stream in other ways didn't really
seem to fit too well.  (Furthermore, having the state and stream be the
same thing would cause complications because the state type needs to be
unique.)

It would certainly be possible to define another class of streams where
the stream type is the state; indeed it may be desirable to have such a
class of streams for precisely the kind of examples you give below.  I'll
need to have a think about it.

> More concretely, converting the RNG typeclass to this protocol
> (see extras/gator/tausworthe3.m) -- it does not depend on io.state to
> update itself -- how would it be converted to conform to typeclass
> stream.input (I image its next/3 method being equivalent to stream.input's
> get/4)? Or samples/e/e.m uses a ones-stream (defined lazily with a base value
> and a closure continuation), how could it be a stream.input?

You could implement such streams with the proposed interface in a similar way
to how I've implemented the buffer stream.

The random typeclass in gator has been cut down a bit.  In the original the
methods also had (mdi, muo) and (di, uo) modes - it was part of a proposal
to add a random number typeclass to the library that I never finished.
There are some random number generators, hardware ones for instance, that
would update the state of the world.

> Using io.state to set/get mutable values gives me the heebee-geebees, even
> though the declarative semantics are maintained.  Is there a functionally
> pure (or, put differently, an 'io.state'-free) approach to using this proposed
> protocol?  If so, example, please? (Pretty please?)

You could certainly generalise the buffer example so that it uses stores
instead of the I/O state, however you're always going to need to have some
sort of state that is destructively update.

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