[m-dev.] stream typeclasses (again)

[Ian MacLarty]

On 28 Feb 2006, at 08:03, Julien Fischer wrote:

>
> Hi,
>
> I've spent a bit more time playing around with the stream typeclass 
> proposal.
> Attached is the (or at least my) latest version plus a number of 
> example
> streams.  (Ian, I think you mentioned you'd done some more work on 
> this as
> well?)
>
> Major changes from last time:
>
> * The error type is now part of the stream typeclass, (it's 
> functionally
>   dependent on the stream type).
>
> * The close method has been removed (for the moment at least)
>

I think there may have been a misunderstanding about what the State 
argument of the stream typeclass is for.  It's supposed to be the state 
that is modified when you read or write from the stream, so for the 
buffer stream it would be the string type.

I've rewritten the buffer module and attached it.  At the moment it 
doesn't take advantage of the unique modes, so we could make it more 
efficient by doing destructive update of the string with foreign code.

Also I think the encryption typeclass should be implemented 
differently.  Instead of writing to the stream to encrypt the data, and 
then reading from the same stream to get the encrypted data, I would 
add an extra argument to the 'new' predicate that creates the stream.  
The extra argument would be the stream to write the encrypted data to.

Consider the situation where you're implementing an encrypted file 
transfer protocol.  Using your design you'd have to either write the 
whole file to the encryption stream and then read it and forward it to 
a socket stream (which would exhaust memory if the file was big), or 
implement some kind of buffering system that would flush the encryption 
stream to the socket at regular intervals.  Using my proposed design 
you'd just create the encryption stream, giving the socket stream as an 
argument, then everytime you write to the encryption stream the 
encrypted data automatically gets forwarded to the socket stream.

In trying to implement this design though I hit some restrictions in 
the typeclass system which I think probably don't need to be there.  
I'll describe these in a separate email.

I still think the 'name' method shouldn't need to alter the state.  
Perhaps we should do away with that method.  I can't see it being 
particularly useful, since I imagine you'd only use the stream name in 
error messages, which can be done by including the name in the Error 
type for the stream.

Another issue we haven't addressed that we will need to before we 
update the std library is what will the notion of the current stream 
mean?  Since we can't store a general stream in a global mutable (and 
it doesn't really make sense to anyway), should we just have the notion 
of the current *file* stream?

Ian.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: string_buffer.m
Type: application/octet-stream
Size: 5189 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/developers/attachments/20060305/9057858f/attachment.obj>