[m-dev.] for discussion: stream library v2

[Peter Ross]

On Wed, Sep 27, 2000 at 06:35:27AM -0700, Ralph Becket wrote:
> >From Peter Ross on 27/09/2000 13:56:17
> >
> > Bytes will need to be added, but they will have to be a seperate type
> > class (stream__binary/stream__binary_input/stream__binary_output).  What
> > you will probably find is that you can reuse all your lowlevel
> > implementation to work on binary streams, you will just need to provide
> > instance declarations.
> > 
> > > Are we not worried about generalising to arbitrary stream types?  For
> > > example, I might want to treat a lexer as an input stream of tokens.
> > > 
> > I don't understand what you are trying to get at here.
> > What does read word mean when your input was a list of tokens?
> > Of course the lexer could be coded in such a way that it takes in a
> > stream of chars (whether it be from a socket/file/stdin/string) and
> > produce a list of tokens.
> 
> I'm thinking of a probably-not-terribly-useful generalisation where a
> stream is an interface to some sequence of `things'; it just happens
> that the `things' are most commonly chars and bytes, but it need not
> be so.  As you say, one can build higher level abstractions on top
> of char/byte streams.
> 
I think you might have been.

> 
> > > I also think there should be some explanation of why all the lowlevel
> > > typeclass methods are impure...
> >
> > They are impure because they were designed to map gracefully onto the
> > foreign function interface.  If you so desire, you can implement you
> > stream interface at a higher level, hopefully getting the best of both
> > worlds.
> 
> That still doesn't explain why they *have* to be impure or
> even declared as such.  Can you give me an example where it's
> necessary to have impure low-level stream code that can't be 
> hidden behind a pure interface?
> 
No I can't give you an example because I already provide an implementation
of low_read_char and low_write_char which provides a pure interface for any
member of the lowlevel type class.  The point is that by defining the
lowlevel interface you also get this pure interface for free.

Now when implementing a stream you can choose to implement an impure
interface (generally what you want to do if you are using a C library)
or you can implement a pure interface (what you want to do if you are
operating on a mercury type).  There is nothing stopping you
from implementing the pure interface for a C library but why bother when
you only have to implement all the impure bits and you also get the pure
interface.

Note however that you must provide a pure interface because the
predicates in stream.m require it.  It is just up to the implementator
to decide which of the two levels it is easiest to implement the
interface at.

Hope this helps,
Pete
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------