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

Ralph Becket rbeck at microsoft.com
Thu Sep 28 00:35:27 AEDT 2000


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

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



More information about the developers mailing list