[m-rev.] for review: io.write for streams

[Julien Fischer]

On Wed, 20 Dec 2006, Simon Taylor wrote:

> On 20-Dec-2006, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>>
>> On Tue, 19 Dec 2006, Simon Taylor wrote:
>>
>>> On 19-Dec-2006, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>>>>
>>>> On Fri, 15 Dec 2006, Simon Taylor wrote:
>>>>
>>>>> Implement io.write for arbitrary streams.  With type specialization
>>>>> this is only slightly slower than the original.
>>>>>
>>>>> library/stream.string_writer.m:
>>>>> 	A module containing predicates for writing to streams
>>>>> 	which accept strings.
>>>>
>>>> Is there a reason that you are putting these predicates in a sub-module of
>>>> stream.m rather than just in stream.m itself?  Also, I'm not crazy about
>>>> the
>>>> name string_writer, it sounds like a set of predicates for contructing
>>>> strings.  At the moment, I guess my preference would be to just add
>>>> everything to stream.m.
>>>
>>> That leads to 8000 line modules like io.m.  If there is a sensible set
>>> of functionality that can be split out, it's better to do it.
>>
>> Suggestions abut how to decompose the io module are welcome as well :-)
>>
>>> I'm open to suggestion on the name, maybe stream.put_string.
>>
>> How about stream.output_util?  I don't see that there's any point having
>> a separate sub-module for string writers at the moment.
>
> It's a nice sized module containing related functionality.
>
>> (By the same token the various folds over input streams that are currently
>> in the stream module could be moved to stream.input_util sub-module.)
>
> The folds are fine where they are because they apply to all instances
> of stream.reader.  We don't have list.foldl in a sub-module of list.m.
>
> If we were going to split things, it would be better to have the input
> typeclasses and the folds both in stream.input.m.  Mercury has no support
> for importing a full path of modules (e.g. stream.input.char) at once, so
> that might be a pain for users.

I don't like the idea of splitting the classes up for just that reason,
I want to be able to import just the stream module and have access to
them all.

> The predicates in stream.string_writer (or whatever it is called) only
> apply to a subset of instances (and a subset of importers), so it makes
> sense to separate them out.
>
> I'd suggest the following organisation:
>
> stream.m
>    stream.output.m		output classes, put_list, etc.
> 	stream.output.char.m	write, format, etc
> 	stream.output.byte.m	write_binary
>    stream.input.m		input classes, folds etc.
> 	stream.input.char.m	read, read_line, read_entire_stream, etc
> 	stream.input.byte.m	read_binary, read_entire_stream
>
> It should be possible to write `:- import module stream.output.char'
> and have it import `stream' and `stream.output' automatically.
>
> This might be overkill, it might be better just to have:
>
> stream.m
>    stream.char.m		write, format, read, read_line, etc.
>    stream.byte.m		write_binary, read_binary, etc.

I prefer the latter suggestion, although if the distinction is going
to be between text and binary streams then the sub-module names ought
to reflect that, e.g.

 	stream.m		[all the typeclasses]
 	stream.text.m		write, format, read, read_line, etc.
 	stream.binary.m		write, read, etc.

Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------