[m-dev.] Minimal streams diff

Michael Day mikeday at yeslogic.com
Wed Oct 2 14:18:00 AEST 2002


Hi Fergus,

> 	- what is the rationale for this change?

 * generic streams are useful functionality
 * making the standard io streams instances of generic streams is 
convenient

This does not require putting the stream interfaces in the io module
itself, but the alternative would be to pull out all the existing stream
stuff from the io module into a separate stream module, which would also
work but be incredibly disruptive to existing code.

 * a minimal patch can give generic stream functionality without screwing 
up existing code

> 	- how does this differ from Peter Ross's stream stuff
> 	  (which I think lives in extras/stream)?

It differs by being included in the io module, which makes life much more
convenient by not having duplicate methods io__read_char and
stream__read_char and duplicate types io__result and stream__result for
what are identical operations. Also allows existing code that uses
standard io streams to be extended to handle generic streams with only a
tiny change.

> Why not have the stream_name predicate in a base class inherited from
> both input and output?

Why? That would just give you another type class to mess around with, with
no particular benefit that I can see, and would make it harder to make a
duplex stream by composing an input and output stream. However I don't
mind to change this if you think it's worth it.

> Wouldn't it be better to name the classes input_stream and output_stream?

Define better :) It would certainly be longer. I must admit, one of the
benefits of having this stuff in a separate stream module is that you can
give people the choice of saying "input" or "stream__input", depending on
their preferred level of verbiage. Oh well, I guess I could rename these 
if they're considered to be unreadable, or so vague that they are 
dangerously ambiguous:

:- pred foo(S, io, io) <= input(S).

What do you think?

Michael

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



More information about the developers mailing list