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

[Ian MacLarty]

On Thu, Feb 16, 2006 at 07:23:58PM +1100, Julien Fischer wrote:
> 
> 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? ;-)
> 

I'd rather not say ;-)

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

Excellent.  I think this will help MC quite a bit too, since they are
using typeclasses extensively.

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

How so?

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

No.

> - buffered vs. unbuffered streams

Perhaps we can just define a `buffer' stream, that connects two other
streams.  I don't see the need for a separate typeclass.

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

No, I think you're right.

Ian.

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