[m-rev.] for review: start integrating stream typeclasses into stdlib

[Julien Fischer]

On Fri, 27 Oct 2006, Ralph Becket wrote:

> Ian MacLarty, Friday, 27 October 2006:
>>
>> Does using the io equivalence type instead of io.state in these instance
>> declarations cause problems?  I'd prefer it if we could use the
>> equivalence type to be more consistent with the rest of the io module.
>>
>> Otherwise that looks fine.
>
> Would there be any problem with making io.io the concrete type and
> io.state the equivalence?

I have no problems with making io.io the concrete type.  Another
alternative that Ian and I discussed yesterday would be to
make io a builtin type, e.g. builtin.io.  (The current io.state and
io.io types could be defined as equivalence types.)  Some reasons
for this are:

* the I/O state is handled specially in a lot of places anyway, it
   seems more natural to group it with the other builtin types like
   ints, floats, strings etc.

* a few of the library modules are importing the I/O module just
   to gain access the to the I/O state, e.g. benchmarking and store,
   but don't need the rest of the stuff in that module.   Not having
   library modules depend on the io module would simplify the library
   module dependency graph.

* mutables attached to the I/O state currently rely on the user to
   explicitly import the io module to gain access to the I/O state.
   (It's easy enough to forget to do this - which can be a bit
   inconvenient).

(And similarly for char/character?)

By making char a proper builtin type?  Yes, that would be good.

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