[m-dev.] streams in Mercury

[Julien Fischer]

On Wed, 14 Dec 2005, Peter Ross wrote:

> > > >
> > > > > Are there any thoughts on this idea?
> > > >
> > > > Search for streams on the mailing list archive.
> > >
> > > There were a lot of results.  I didn't see anything to suggest my
> > > proposal is a bad idea.
> > >
> >
> > My point was that there has already been a good deal of discussion
> > about streams and associated issues.
> >
> It was a long time ago we discussed this, from what I remember the
> consensus was try out my design and see how it works and then report
> back.  Consider this the report back. ;)
>
> In fact we have used it extensively now and it works well.  There is
> only one slight hack and that is we had to define write_string as a
> typeclass method, as writing one char at a time to sockets is incredibly
> expensive.
>
> We currently use it for sockets, ssl and logging what we are writing
> over our ssl stream to a file.

>From the sound of it we probably should include it in the standard
library then.

...

>
> > > > > I thought of using the new MercuryFile C type, but that approach has two
> > > > > problems:
> > > > >    1.  It requires writing C code to implement a new type of stream.
> > > > >    2.  It requires the compiler to be built with a special flag to turn
> > > > >        on the use of this structure.
> > > > >
> > > >
> > > > We could use the MercuryFile structure by default, although the question
> > > > then becomes what sort of overhead is that going to entail?  Do MC have
> > > > any figures on how the MercuryFile struct compares to normal files?
> > > > (If not then that can be another job for Samrith ;-))
> > > >
> > >
> > > The overhead ratio will depend on what kind of stream you're writing to.
> > >
> >
> > I was referring to stdin and stdout.
> >
> For the MercuryFile the overhead will be one extra pointer lookup to
> find which underlying C function to call no matter what the underlying
> stream is.  So very slight.
>

It seems somewhat more than very slight here:

<http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-developers/mercury-developers.0008/0099.html>

but maybe things have changed since then?

> > > Using MercuryFile you will always have to do a pointer lookup, but using
> > > typeclasses presumably you could specialise the dereference away for
> > > common instances.
> > >
> >
> > You may be overestimating how well we optimize code involving
> > typeclasses.
> >
> However it is possible to optimize away this overhead, but maybe it's not
> implemented yet. So I don't think this is a good reason to not use a
> stream typeclass.

No, but depending on the performance impact (if any) it may be good reason for
not implementing the predicates in the io module in terms of the stream
typeclasses (as Ian was suggesting).

Cheers,
Julien.


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