[mercury-users] string_stream impl, re: redirecting output to streams

Julien Fischer juliensf at cs.mu.OZ.AU
Thu Feb 16 19:23:58 AEDT 2006


On Wed, 15 Feb 2006, Ian MacLarty wrote:

> On 15 Feb 2006, at 06:21, doug.auclair at logicaltypes.com wrote:
>
> > Dear Ralph,
> >
> > Thank you for your response, which was:
> >
> >> The short answer is "not yet".  But we're working on it.
> >
> > Okay.  What remains to be done?  Would it be possible to send me the
> > work in progress so I can complete the implementation?  If all you
> > have is notes, that is fine, too, as I have a working familiarity with
> > the compiler.
> >
>
> I think Ralph is refering to the streams proposal I posted a few weeks
> ago.  It can be found at the following address:
> http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-
> developers/mercury-developers.200601/0012.html.
>
> There is an attached draft of a streams.m library with that post.
>
> In my email I said that we would leave the operations in io.m to only
> work on io.input_stream and io.output_stream for performance reasons,
> but I now think it would be quite useful if io.read and io.write also
> worked on general streams.
>
> In my opinion what needs to be done is the following:
>
> 1.  implement io.read and io.write to work on the stream typeclass in
> streams.m (the file from my post mentioned above, not the one in
> extras).  This, I think, will also require term_io to be modified to
> work on the streams typeclass.
>
See below - we now need this for the compiler.

> 2.  Asses what the performance impact on the compiler is and whether
> it's acceptable.

What do donkeys have to do with it? ;-)

Avoidable is probably more important that acceptable in the long run.
If the main overhead is from typeclass dictionary lookups then we should
be able to optimise a lot of that away; I was planning to look at that
later this year anyway.

> 3.  term_to_xml should also be rewritten to work with the streams
> typeclass.
>
> 4.  implement other useful streams such as string buffers, sockets, etc.

I'd like to get this proposal sorted and implemented because reading terms
from strings has just become an issue with the compiler.  Some other details
with the streams proposla that need to be ironed out:

- duplex streams
	- extras/streams includes these; is there a reason they were
	  omitted from your proposal?

- buffered vs. unbuffered streams
- putback

My immediate impression is that it should just be a matter of adding the
appropriate typeclasses for these things but maybe I've missed something?

Julien.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the users mailing list