[m-dev.] streams in Mercury

[Ian MacLarty]

On Wed, Dec 14, 2005 at 02:58:26AM +1100, Julien Fischer wrote:
> 
> 
> Some initial comments/questions:
> 
> On Wed, 14 Dec 2005, Ian MacLarty wrote:
> 
> > Hello,
> >
> > At MC we're using many different streams besides normal file streams
> > (such as sockets, ssl and logging streams).  Peter has therefore defined
> > some stream typeclasses and rewritten some parts of io.m for reading and
> > writing to general streams.
> >
> 
> How similar are the stream typeclasses to the stuff in extras/stream?
> 

Very similar.

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

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

Using MercuryFile you will always have to do a pointer lookup, but using
typeclasses presumably you could specialise the dereference away for
common instances.

Also it'd be easier to add Mercury only streams using typeclasseses
(such as a compression stream).  Using MercuryFile you always have to do
some foreign code, and you have to do foreign code for each backend you
want to support, whereas if you use types classes and the stream is
implemented in pure Mercury you get all backends for free.

Another reason MercuryFile is not a good idea is because it's
interaction with the debugger is problematic: if the implementations of
the read, write and close functions are all C code, then the
foreign_proc that calls them should be tabled_for_io.  If they are
Mercury functions or call Mercury functions then the foreign_proc must
not be tabled_for_io.  But what those functions are is only known at
runtime.


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