Comments for The Comonad.Reader http://comonad.com/reader types, (co)monads, substructural logic Fri, 27 Apr 2012 05:01:00 -0400 http://wordpress.org/?v=2.8.4 hourly 1 Comment on Free Monads for Less (Part 2 of 3): Yoneda by Philip J-F http://comonad.com/reader/2011/free-monads-for-less-2/comment-page-1/#comment-104638 Philip J-F Fri, 27 Apr 2012 05:01:00 +0000 http://comonad.com/reader/?p=243#comment-104638 shouldn't the type of improve be Functor f => (forall m. MonadFree f m => m a) -> Free f a instead of (forall a. MonadFree f m => m a) -> Free f a shouldn’t the type of improve be

Functor f => (forall m. MonadFree f m => m a) -> Free f a

instead of

(forall a. MonadFree f m => m a) -> Free f a

]]> Comment on The Cofree Comonad and the Expression Problem by Richard Wallace http://comonad.com/reader/2008/the-cofree-comonad-and-the-expression-problem/comment-page-1/#comment-104596 Richard Wallace Tue, 24 Apr 2012 01:11:23 +0000 http://comonad.com/reader/2008/the-cofree-comonad-and-the-expression-problem/#comment-104596 I've really enjoyed studying and trying to understand this, but one thing has still got me hung up that I just can't seem to get past. I've been trying, as an exercise, to get the addition example from Swierstra’s paper working in terms of Free and Cofree. I translated Expr to Free successfully and am able to right an eval function eval :: (Eval f, Functor f) => Free f Int -> Int that works using cataFree. I've also taken the next step and eliminated the Eval type-class and written runArith and runVal functions that I can then compose in the way outlined in the comment above. But I just can't seem to take that mental leap to translate it using Cofree. I think my problem is in determining what the dual of Addition and Val should be. An example of that would be greatly appreciated and hopefully shine light the last bits that are still eluding me. Thanks. I’ve really enjoyed studying and trying to understand this, but one thing has still got me hung up that I just can’t seem to get past.

I’ve been trying, as an exercise, to get the addition example from Swierstra’s paper working in terms of Free and Cofree. I translated Expr to Free successfully and am able to right an eval function

eval :: (Eval f, Functor f) => Free f Int -> Int

that works using cataFree. I’ve also taken the next step and eliminated the Eval type-class and written runArith and runVal functions that I can then compose in the way outlined in the comment above.

But I just can’t seem to take that mental leap to translate it using Cofree. I think my problem is in determining what the dual of Addition and Val should be.

An example of that would be greatly appreciated and hopefully shine light the last bits that are still eluding me.

Thanks.

]]> Comment on Wadler’s Law Revisited by sclv http://comonad.com/reader/2012/wadlers-law-revisited/comment-page-1/#comment-104342 sclv Wed, 04 Apr 2012 17:19:41 +0000 http://comonad.com/reader/?p=571#comment-104342 The module system is an easy fix by comparison! (w/r/t nested modules only that is... once we get into ML/functors territory the can of worms/gate to hellmouth starts to open up.) The module system is an easy fix by comparison! (w/r/t nested modules only that is… once we get into ML/functors territory the can of worms/gate to hellmouth starts to open up.)

]]> Comment on Wadler’s Law Revisited by Edward Kmett http://comonad.com/reader/2012/wadlers-law-revisited/comment-page-1/#comment-104329 Edward Kmett Wed, 04 Apr 2012 05:34:34 +0000 http://comonad.com/reader/?p=571#comment-104329 Pseudonym: Of course. :D In general the 'strong record conjecture' can be viewed of as just a version of wadler's original law, with a subset of the semantics separated out, since if you factor out the 2^4 factor, it IS the same law (modulo comments), but you could go back to the original 1992 version of the law, and ... finish killing the joke completely. Pseudonym: Of course. :D In general the ’strong record conjecture’ can be viewed of as just a version of wadler’s original law, with a subset of the semantics separated out, since if you factor out the 2^4 factor, it IS the same law (modulo comments), but you could go back to the original 1992 version of the law, and … finish killing the joke completely.

]]> Comment on Wadler’s Law Revisited by Pseudonym http://comonad.com/reader/2012/wadlers-law-revisited/comment-page-1/#comment-104328 Pseudonym Wed, 04 Apr 2012 05:02:53 +0000 http://comonad.com/reader/?p=571#comment-104328 Both record conjectures are incorrect in the sense that Wadler's Law is, because Wadler's Law applies to <i>all</i> language designs, not just ones with an existing record design which doesn't do the job. If you extrapolated from only C++ discussions to all language design discussions, this would be called the Weak Concept Conjecture instead. I have a suspicion that every programming language has a missing but highly desirable feature, or existing but broken realisation of said feature, that everyone would like fixed, but most obvious ways to fix it would have nontrivial interactions with existing features or libraries and/or break a lot of existing code. BTW, if you think the Haskell records discussion is bad, you wait until someone bites the bullet on the module system. Both record conjectures are incorrect in the sense that Wadler’s Law is, because Wadler’s Law applies to all language designs, not just ones with an existing record design which doesn’t do the job.

If you extrapolated from only C++ discussions to all language design discussions, this would be called the Weak Concept Conjecture instead.

I have a suspicion that every programming language has a missing but highly desirable feature, or existing but broken realisation of said feature, that everyone would like fixed, but most obvious ways to fix it would have nontrivial interactions with existing features or libraries and/or break a lot of existing code.

BTW, if you think the Haskell records discussion is bad, you wait until someone bites the bullet on the module system.

]]> Comment on What Constraints Entail: Part 2 by Philip J-F http://comonad.com/reader/2011/what-constraints-entail-part-2/comment-page-1/#comment-103013 Philip J-F Thu, 01 Mar 2012 07:04:59 +0000 http://comonad.com/reader/?p=461#comment-103013 Inspired by this discussion I wrote a post showing how to get multiple, passable, effectively first-class, instances. I borrowed your applicative example: http://joyoftypes.blogspot.com/2012/02/haskell-supports-first-class-instances.html Inspired by this discussion I wrote a post showing how to get multiple, passable, effectively first-class, instances. I borrowed your applicative example: http://joyoftypes.blogspot.com/2012/02/haskell-supports-first-class-instances.html

]]> Comment on Searching Infinity Parametrically by Ryan Ingram http://comonad.com/reader/2011/searching-infinity/comment-page-1/#comment-101855 Ryan Ingram Wed, 22 Feb 2012 23:43:08 +0000 http://comonad.com/reader/?p=510#comment-101855 Hm, I changed my mind. effectify requires you to order all the calls inside the otherwise pure f, which violates referential transparency; in (\k :: (String->Int) -> k "a" + k "b") (with strict (+)), the compiler is allowed to choose whether it wants to evaluate k "a" or k "b" first, while in the effectful version the caller needs to explicitly make that decision. Hm, I changed my mind. effectify requires you to order all the calls inside the otherwise pure f, which violates referential transparency; in (\k :: (String->Int) -> k “a” + k “b”) (with strict (+)), the compiler is allowed to choose whether it wants to evaluate k “a” or k “b” first, while in the effectful version the caller needs to explicitly make that decision.

]]> Comment on Searching Infinity Parametrically by Ryan Ingram http://comonad.com/reader/2011/searching-infinity/comment-page-1/#comment-101849 Ryan Ingram Wed, 22 Feb 2012 23:02:20 +0000 http://comonad.com/reader/?p=510#comment-101849 One thing that's interesting to me is the transformation from type Pure a b c = (a -> b) -> c to type Effect a b c = forall f. Monad f => (a -> f b) -> f c Clearly f_effect is pure; you can get f_pure from f_effect by specializing f to the identity monad: purify :: Effect a b c -> Pure a b c purify f ab = runIdentity $ f $ \a -> Identity $ ab a But it seems to me that no unsoundness is introduced by allowing this isomorphism in the other direction as well, although I don't think that's implementable in Haskell. effectify :: Pure a b c -> Effect a b c effectify f = ??? One thing that’s interesting to me is the transformation from

type Pure a b c = (a -> b) -> c

to

type Effect a b c = forall f. Monad f => (a -> f b) -> f c

Clearly f_effect is pure; you can get f_pure from f_effect by specializing f to the identity monad:

purify :: Effect a b c -> Pure a b c
purify f ab = runIdentity $ f $ \a -> Identity $ ab a

But it seems to me that no unsoundness is introduced by allowing this isomorphism in the other direction as well, although I don’t think that’s implementable in Haskell.

effectify :: Pure a b c -> Effect a b c
effectify f = ???

]]> Comment on Zipping and Unzipping Functors by anonymous http://comonad.com/reader/2008/zipping-and-unzipping-functors/comment-page-1/#comment-101831 anonymous Wed, 22 Feb 2012 20:29:32 +0000 http://comonad.com/reader/2008/zipping-and-unzipping-functors/#comment-101831 I also want liftPair in Applicative I also want liftPair in Applicative

]]> Comment on The Pointed-Set Comonad by anonymous http://comonad.com/reader/2008/the-pointed-set-comonad/comment-page-1/#comment-101828 anonymous Wed, 22 Feb 2012 20:02:18 +0000 http://comonad.com/reader/2008/the-pointed-set-comonad/#comment-101828 Anything with mzero (or empty) cannot be a comonad, as far as I can tell; extract and mzero are mutually exclusive. Anything with mzero (or empty) cannot be a comonad, as far as I can tell; extract and mzero are mutually exclusive.

]]>