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

[doug.auclair at logicaltypes.com]

Dear Julien, thank you for your work on the stream proposal.  You 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.

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?

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?

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

Sincerely,
Doug Auclair

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