On 9/7/10 12:33 AM, Ivan Lazar Miljenovic wrote:
On 7 September 2010 14:24, wren ng thornton<w...@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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
