On 30 Nov 2010, at 16:05, David Menendez wrote:

I contend that there is little benefit to splitting Applicative. By itself, 'pure' is simply too loosely defined.

It would be more interesting to have a type class for those functors which were not pointed. Relatively speaking. Cheers Conor

On 1 Dec 2010, at 10:44, John Lato wrote:

On Wed, Dec 1, 2010 at 12:17 AM, Conor McBride

...

wrote:

On 30 Nov 2010, at 16:05, David Menendez wrote:

I contend that there is little benefit to splitting Applicative. By itself, 'pure' is simply too loosely defined.

It would be more interesting to have a type class for those functors which were not pointed. Relatively speaking.

I'm completely lost now. Do you mean something other than Functor? What do you have in mind?

I was being slightly facetious. I was also wondering what value the Pointed class would add, by asking which instances of Functor would fail to be Pointed. The constantly Zero (or Void, if you insist) Functor? What else? I suggest that failure to be Pointed is a more curious and interesting property of a Functor than being Pointed, but I don't quite see a compelling case for either situation having a class to itself. Sorry to be oblique Conor

On 2 Dec 2010, at 08:04, Roman Leshchinskiy wrote:

On 01/12/2010, at 13:04, Conor McBride wrote:

...

I was being slightly facetious. I was also wondering what value the Pointed class would add, by asking which instances of Functor would fail to be Pointed. The constantly Zero (or Void, if you insist) Functor? What else?

Any tuple type. Or, more generally, any multifunctor or anything that carries more information than just the a.

I can see that we're not going to get instance Pointed ((,) a) anytime soon, but is that the thing we'd want anyway? 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 Now, write a theorem prover! instance Inhabited () where something = () instance (Inhabited a, Inhabited b) => Inhabited (a, b) where something = (something, something) Wouldn't that give us instance Inhabited a => Pointed ((,) a) ? Or, slightly more scarily, but without an extra class instance Pointed (Const a) => Pointed ((,) a) where pure b = (getConst (pure ()), b) 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. However, fun though it may be, I see no evidence yet that the game is worth the candle. All the best Conor

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 <snip> 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