[m-dev.] streams in Mercury

[Ralph Becket]

Julien Fischer, Friday, 16 December 2005:
> 
> Yes, but I wouldn't want it to take three times as long for something
> that did a large amount of I/O.

But it wouldn't: disc speeds are still much the same, processor speeds
are up a factor of eight or sixteen!

> > (and given that this experiment was conducted five years ago, I'd wager
> > that by now the relative difference in user to real time is tiny).
> >
> 
> Which was why I asked if anyone had any up-to-date figures further
> back in this thread.

Pete, can you resolve this one by re-running the test?  Ta!

> > I'd go the other way and vote for the greater generality of the streams
> > interface and the s/w engineering benefits of not having special-case
> > code lying around.
> 
> What special case code?

As I understand it, you're suggesting we duplicate functionality for the
streams based code and in the IO library.  I'm saying we should just
implement core functionality in the streams instances and then use
streams for all things IO.

> > If it does become an issue, we know what we have to do to improve matters.
> >
> 
> A volunteer ;-)

A non-sequiteur :-)

> So the as I see it there three proposals here:
> 
> 	(1) add the stream typeclasses to the standard library
> 	(2) reimplement the io module in terms of (1)
> 	(3) use the MercuryFile struct by default
> 
> I'm happy for (1) to go ahead now and for (2) and (3) to got ahead
> provided they do not have a significant impact on the performance of the
> compiler.

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