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

[Michael Day]

Hi Doug,

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

This is something that I found troubling six years ago when I was trying
to implement a stream type class in Mercury (what goes around... :)

Ultimately though, it made sense once I looked at it from the perspective
of a predicate doing something with a stream. It doesn't know what type of
stream it is using, and if it's a file stream for example then stream
operations will update the IO state. So, the predicate needs to
destructively update something. Making it a generic state type can
complicate predicates that also need the IO state to do other things, as
they then run the risk of updating two IO states, which isn't going to
work.

So, predicates that read from/write to streams need to destructively
update the IO state, as the stream they're using might be a file. (Thanks
to Fergus for this inspiration if I remember correctly).

If you really want to access pure streams, sequences, string buffers, etc.
you would need a distinct API for them.

Cheers,

Michael

-- 
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------