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

Peter Ross petdr at miscrit.be
Wed Sep 27 23:51:27 AEDT 2000


On Wed, Sep 27, 2000 at 03:19:43AM -0700, Ralph Becket wrote:
> [Previous version was sent prematurely].
> 
> Umm, I'm not sure I'm happy with this being restricted to chars.  At
> the very least, bytes would be better.
> 
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 also think there should be some explanation of why all the lowlevel
> typeclass methods are impure.  I still don't see why they shouldn't have
> pure di/uo signatures.  It doesn't matter if they change the state of
> the world thanks to the semantics of unique objects.  For example,
> arrays are implemented in C, but still have a pure di/uo interface.
> Having several streams playing around with IO is still fine - it's no
> different to having multiple threads doing IO.
> 
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.

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



More information about the developers mailing list