[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