[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