[m-rev.] for review: delete see/seen/tell/told from io.m

[Zoltan Somogyi]

2022-03-05 18:51 GMT+11:00 "Julien Fischer" <jfischer at opturion.com>:
>> An issue just came up when I moved the code for reading/writing
>> bitmaps to bitmap.m: where should we keep the various  instances of typeclasses
>> such as stream.bulk_reader and stream.writer that say how to read/write
>> non-primitive types? Specifically, if the reading/writing code for that type
>> has been moved to another module, should the instance declarations
>> go with them, or should they stay in io.m?
>>
>> I can see arguments in favor of both answers. Logically, an instance that
>> implements a typeclass method using a predicate should be in the module
>> that defines that predicate. OTOH, this may require modules to import
>> the modules that define the typeclasses just for the sake of the instance
>> declaration, and it makes checking whether a class has an instance for
>> a given type harder.
> 
> Since those instances are for types (i.e. io.state and bitmap) from both
> modules, they could be resasonably declared in either.
> 
> On balance, I favour moving them to bitmap.m.

The attached diff, which I just committed, does that.

The diff does raise an issue. io.m had three instances involving bitmaps,
but only two were exported; one was not. Since io.m exported the fact
that bitmap.slice is a member of a typeclass, but did not export the fact
that bitmap itself is a member of that same typeclass, I think this is
a bug, but since I never worked with bitmaps, I am not sure. Does anyone
know?

Also, I noticed that in io.m, the abstract and concrete instance declarations
are not in the same order. I intend to put them into the same order;
this should reveal whether there are any more intentionally unexported
instances.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.bsi
Type: application/octet-stream
Size: 4545 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20220308/594342f2/attachment.obj>