[Haskell-cafe] Restricted type classes
Ivan Lazar Miljenovic
ivan.miljenovic at gmail.com
Tue Sep 7 00:04:37 EDT 2010
On 7 September 2010 12:18, wren ng thornton <wren at freegeek.org> wrote:
> On 9/6/10 2:35 AM, Ivan Lazar Miljenovic wrote:
>> Well, if we consider what this does, pure is equivalent to singleton
>> for container types. The actual definition of pure (or any other
>> aspect of Pointed) doesn't require Functor; however there are
>> properties for types that are instances of Functor and Pointed.
> Right, that's what I was meaning to highlight. If we were doing this in Coq,
> for example, then not having Functor as a superclass of Pointed would mean
> that we'd need a third class PointedFunctor which has both as superclasses.
> In Haskell, since we don't have proofs, PointedFunctor wouldn't have any
> methods and would therefore just be unnecessary complication. Though this
> raises the question of which one makes more sense to keep around: Pointed
> (with no superclass), or PointedFunctor.
>> So, from a proof/testing POV having Functor as a superclass is nice;
>> from an implementation POV it doesn't seem to be needed.
> Though, again, I wonder what the use case would be. Your example of
> singleton collections doesn't seem quite right. I'd expect the singleton
> functions to obey various "spatial" laws (i.e., module-like or vector
> space-like laws). For example,
> union (singleton a) x = insert a x
> This isn't exactly like Applicative because 'a' is an element instead of a
> function. And it's not quite like Alternative either, since it only requires
> union to be a semigroup instead of a monoid.
Well, I think the ability to create singleton values is a nice
function to abstract away into a type class. Whether we can prove
something or not is, however, a different story.
> Perhaps this just means that union/insert should be part of some other
That is part of the plan (I'm tentatively calling the class with the
"insert" method "Buildable" or "Extendable"); this means that if a
type is an instance of Monoid (for mempty), Buildable/whatever (for
insert) and Foldable (for foldr), then we can possibly define a
build-fusion rule (note: I dont' think this will work on Sets, etc.
unless we have some way of guarantee-ing that the folding function is
strictly monotonic). Note also that we can then define that singleton
= flip insert mempty (but in general this might not be ideal; Sets,
for example, don't have the Ord constraint for singleton).
> Of course, I'd expect singleton to obey the pointed law as well, so
> that other class would (most likely) be a subclass of pointed functors. In
> any case, it does mean there's something of a mismatch between singleton vs
Not quite sure what you mean by a "mis-match"
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
More information about the Haskell-Cafe