[m-dev.] streams proposal (part 2)

[Ian MacLarty]

On 23 Feb 2006, at 23:35, Ralph Becket wrote:

> Ian MacLarty, Friday, 24 February 2006:
>> On Tue, Feb 21, 2006 at 05:48:29PM +1100, Julien Fischer wrote:
>>> :- typeclass stream.error(Error) where
>>> [
>>>     % Convert a stream error into a human-readable format.
>>>     % e.g. for use in error messages.
>>>     %
>>>     func error_message(Error) = string
>>> ].
>>>
>>
>> I don't think this is a particularly useful way to do errors.  In my 
>> opinion
>> it would be better to add an extra Error argument to the stream 
>> typeclass and
>> make Error functionally dependent on Stream.  That way you can do more
>> with a returned error than simply converting it to a string (since 
>> you'll
>> know its ground type).
>
> I agree: making the IO errors entirely opaque was probably a mistake.
> It could be handy to know whether a file write failed because the 
> stream
> was closed or the device was full or whatever.
>
>>>     % The root of the stream class hierarchy.
>>>     %
>>> :- typeclass stream(Stream, State)
>>>     <= (Stream -> State) where [
>>>
>>>     % A human readable name describing the stream.
>>>     %
>>>     pred name(Stream::in, stream.name::out, State::di, State::uo) is 
>>> det,
>>>
>>
>> I would prefer this to be
>>
>>     func name(Stream) = string,
>>
>> but for the moment it has to have the State, because io.input_stream 
>> needs to
>> read the I/O state to access the stream info database.
>
> That's odd: why wouldn't a stream carry its name?
>

It's just the way the current io streams have been implemented.
I don't see why we can't store the name with the stream itself and
not with the state.

>>> %
>>> % Putback streams
>>> %
>>>
>>> :- typeclass stream.putback(Stream, Unit, State)
>>>         <= stream.input(Stream, Unit, State) where [
>>>
>>>     pred unget(Stream::in, Unit::in, State::di, State::uo) is det
>>> ].
>>>
>>
>> How would unget work?  What happens if I get an 'a', but then unget a 
>> 'b'?
>
> I believe (I may be wrong) that in the C IO library you can do just 
> that!
>
>>> %
>>> % Seekable streams
>>> %
>>>
>>> :- type stream.whence
>>>     --->    set
>>>     ;       cur
>>>     ;       end.
>>
>> Should the set function symbol have an argument?
>
> No, these are relative positions.  They are always given with a 
> separate
> argument (e.g., "100 bytes from the start/current point/end of the
> stream").
>

Oh right.  I get it now.

> Well, you could store it in a global univ mutable, but
>
>

Store the stream?  But you need the unit type to
to determine the correct method to call.

I don't think it's such a big deal not having the
current input/output stream.  We could still have
the current input and output *file* streams.

Ian.

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