Functor => Pointed => Applicative => Monad

Tyson Whitehead twhitehead at
Thu Dec 2 22:38:35 CET 2010

On December 2, 2010 04:57:45 Conor McBride wrote:
> Seems a bit peculiar to me, given that Pointed f basically asserts
> the inhabitation of f (). Why don't we just have an Inhabited
> class?
>   class Inhabited x where
>     something :: x
> Then we can build Pointed once for all
>   instance Inhabited (f ()) => Pointed f where
>     pure x = fmap (uconst x) something where
>       uconst :: x -> () -> x
>       uconst = const
> And we can all have fun writing Djinn in type class prolog (didn't
> Oleg do that already?) until somebody points out that every type is
> inhabited by bottom.

Doesn't this pretty much bring us back to my earlier email with

pure x = fmap (const x) undefined

which has obviously problems if fmap tries to take apart the undefined in any 
non-lazy way (e.g., as it will have to for something like the list monad)?

Returning to Poinrted=>Functor vs Functor=>Pointed, it really does seem like 
there may be something to saying functoriality seems a lot closer to building 
on pointedness then pointedness is to building on functoriality.  Wren said

On November 30, 2010 00:32:18 wren ng thornton wrote:
> Not all functors are pointed therefore Pointed=>Functor is invalid.

but, as I think your email argued, this may be equally pedantic to not all 
pointed things are functors as so Functor=>Pointed must also be invalid?

Personally, I think something like an embedded DSL might have reason to want 
to let embed values (i.e., be pointed) but not lift functions to functions 
over embed values (i.e., be functorial).  I think these should be separate.

Cheers!  -Tyson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the Libraries mailing list