[m-dev.] for review: stream I/O

[Ralph Becket]

>From Fergus Henderson on 03/10/2000 02:04:43
> 
> The only time enforcing a total order on the operations of different
> streams makes any sense is when the streams in question have some
> shared state.  For non-io streams, I suspect that is a fairly rare
> case.  However, I guess it would make sense to allow user-defined
> streams which use `store__store' or something like that rather than
> `io__state'.  This would mean that you'd need a multi-parameter
> type class: one parameter would be the stream handle type, and
> the other parameter would be the stream state type.

I can give you an example: I want to test the performance of a
computation that typically will be used on IO streams, but without
counting the cost of doing the IO - so I set up a test harness that
uses strings or arrays.  In this case I may well need to synchronize
operations on one or more input and output streams.

> > As I say, I'd rather have an higher level stream abstraction which
> > included stuff like read_word/line, ignore_whitespace etc. as
> > methods since (a) we're going to provide default method implementations
> > RSN (so I'm told (except for the RSN bit :)) and (b) a stream
> > implementation should be free to use more efficient methods than the
> > default implementations (e.g. clever buffering & read-ahead).
> 
> Well, I think for now we should probably keep things simple --
> the design problem seems hard enough already ;-)
> If/when we add support for default methods, we can make some of
> the higher level procedures as methods to the existing type classes.

Sure, if we have a generic procedure we can add it as a default
implementation later when that facility becomes available.

> One procedure which is definitely worth optimizing in this fashion
> is read_file_as_string (or read_stream_as_string, or whatever we
> call the stream version).  But for read_word/line, ignore_whitespace,
> etc., I'd just make them ordinary procedures rather than class methods,
> at least in the short term.

[Slight misgiving: I'd like to see read_stream_as_array in 
there (with optimizations in array.m to handle char types efficiently)
since one can't do in-place manipulation of strings.]

But other than that, I agree.

Ralph

--
Ralph Becket      |      MSR Cambridge      |      rbeck at microsoft.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
--------------------------------------------------------------------------