[Haskell-cafe] Restricted type classes

[wren ng thornton]

On 9/7/10 12:33 AM, Ivan Lazar Miljenovic wrote:
> On 7 September 2010 14:24, wren ng thornton<wren at freegeek.org>  wrote:
>> On 9/7/10 12:04 AM, Ivan Lazar Miljenovic wrote:
>>> Not quite sure what you mean by a "mis-match"
>>
>> Just that they're not the same thing. For example, ZipList supports pure but
>> it has no meaningful instance of singleton since every ZipList is infinite.
>
> Huh; didn't know that ZipList did that.  OK, so there's a definite
> mis-match between what we'd want a "singleton" function to do and what
> pure appears to do.  How can we specify such a hierarchy given that
> for the majority of containers they will be the same?

The way I'd probably do it is to have one class for pointed functors 
which obeys the pointed law and interacts with Applicative and Monad in 
the expected way; and then have a separate class for singletons which 
has laws about how singleton, insert/cons, coinsert/snoc, and 
union/concat interact. Thus, we'd have two separate functions 
pure/return/unit and singleton, pulling in the class constraints as 
appropriate. For most containers it would just happen that they could 
define pure=singleton, though the class structure doesn't _require_ 
that. This would allow us to avoid excluding containers like ZipList 
(pure, but no singleton) and bloomfilters (singleton, but no pure).

I think the shape of the classes for singletons, insert, coinsert, and 
union still needs some work. For instance, the definitions I've given 
earlier were assuming a (multi)set-like or sequence-like container, but 
we can also reasonably extend it to include map-like containers. The 
only trick is that set/seq-like containers have a single type parameter 
and a single element argument, whereas map-like containers have a pair 
of type parameters and a key--value pair of "elements". So we'd need to 
do something with MPTCs in order to unify them.

-- 
Live well,
~wren