[m-dev.] Minimal streams diff

[Fergus Henderson]

On 02-Oct-2002, Michael Day <mikeday at yeslogic.com> wrote:
> 
> Hi Fergus,
> 
> > 	- what is the rationale for this change?
> 
>  * generic streams are useful functionality

OK, fair enough.

>  * making the standard io streams instances of generic streams is 
> convenient

Agreed.

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

What's wrong with leaving the existing stuff in the io module?

Right now, at least, the compiler is unlikely to do a great job of
optimizing cross-module type class method calls.  So the existing stuff
is going to be more efficient, anyway.  Best to leave it there as
an alternative.

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

Sure, but extras/stream already does that.

It seems like a bad idea to have two different sets of classes that
handle stream functionality.  If you're going to add some stream
functionality to the standard library, then I think it would
make sense to at the same time modify the code in extras/streams
to use the standard library functionality rather than duplicating it.

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

Here I disagree.  These methods are not functional duplicates,
because io__read_char is likely to be more efficient than
stream__read_char (see above).

> and duplicate types io__result and stream__result for
> what are identical operations.

I agree that these are bad.  A patch to change extras/stream
to use io__result rather than stream__result would be very welcome, IMHO.
(Or just to define stream__result as equivalent to io__result.)
This would go along with the bit of your patch that added a way
to create io__error values from strings.

> Also allows existing code that uses
> standard io streams to be extended to handle generic streams with only a
> tiny change.

True, but this also comes at a cost of making existing code significantly
less efficient (at least in the case when intermodule optimization is
not enabled, and maybe in that case too).

Right now I'd prefer that existing monomorphic code stay monomorphic.
(We could reconsider this if/when our optimization technology improves.)

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

The benefit is that you only need to define the name once,
and that code which only uses the name (e.g. error handling routines)
can be made polymorphic over both input and output streams,
rather than needing to be duplicated for both kinds.

But I see what you mean about duplex streams.
So there are two sides to this argument.

I suppose I don't mind too much either way.

Given that I'd rather have just one set of classes for streams,
there is a backwards compatibility argument in favour of the
approach used in extras/streams.

So, to summarize:

	- this patch is not OK because it will make things inefficient,
	  given our current optimization technology

	- a big part of the benefit can be achieved by just changing
	  extras/stream to use io__result; I encourage you to post a
	  patch for this

	- there might be an argument for moving some or all of the
	  functionality in extras/stream into the standard library;
	  I'd be happy to consider any proposals you have in this area.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------