category-theory

问题 Hask looks like a subcategory of the SET - category of all sets and single-argument functions between them. However, seems like it fails to preserve id when it comes down to the undefined : seq undefined () fails with exception as it suppose to, however seq (undefined . id) () = seq (id . undefined) () = () . Obviously, id acts wrongly. Is there a way to (theoretically at least) resolve this issue and make Hask a category indeed? Except throwing undefined away? 来源： https://stackoverflow.com

问题 In terms of pithy summaries - this description of Monads seems to win - describing them as a 'type for impure computation'. What is an equivalent pithy (one-sentence) description of a comonad? 回答1: "A type for context-dependent computation" Alternatively, a better "pithy description" for monads might be a 'type for output impurity', in which case then the pithy description for comonads is a 'type for input impurity'. (If you are interested in comonads, some more introduction is given in some

问题 Lets say I have the following import Control.Category (Category, (.), id) data Invertible a b = Invertible (a -> b) (b -> a) instance Category Invertible where id = Invertible Prelude.id Prelude.id (Invertible f f') . (Invertible g g') = Invertible (f Prelude.. g) (g' Prelude.. f') invert (Invertible x y) = Invertible y x Note that the following is true: invert (g . f) == invert f . invert g This structure seems very similar to a contravariant functor (wikipedia), as it follows the same axiom

问题 This answer from a Category Theory perspective includes the following statement: ...the truth is that there's no real distinction between co and contravariant functor, because every functor is just a covariant functor. ... More in details a contravariant functor F from a category C to a category D is nothing more than a (covariant) functor of type F : C op →D, from the opposite category of C to the category D. On the other hand, Haskell's Functor and Contravariant merely require fmap and

问题 This answer from a Category Theory perspective includes the following statement: ...the truth is that there's no real distinction between co and contravariant functor, because every functor is just a covariant functor. ... More in details a contravariant functor F from a category C to a category D is nothing more than a (covariant) functor of type F : C op →D, from the opposite category of C to the category D. On the other hand, Haskell's Functor and Contravariant merely require fmap and

问题 In the ``Kan Extensions for Program Optimisation'' by Ralf Hinze there is the definition of List type based on right Kan extension of the forgetful functor from the category of monoids along itself (section 7.4). The paper gives Haskell implementation as follows: newtype List a = Abstr { apply :: forall z . (Monoid z) => (a -> z) -> z } I was able to define usual nil and cons constructors: nil :: List a nil = Abstr (\f -> mempty) cons :: a -> List a -> List a cons x (Abstr app) = Abstr (\f ->

问题 While reading the description of Functors on this blog: https://hseeberger.wordpress.com/2010/11/25/introduction-to-category-theory-in-scala/ there is a generic definition of Functor and a more specific one: trait GenericFunctor[->>[_, _], ->>>[_, _], F[_]] { def fmap[A, B](f: A ->> B): F[A] ->>> F[B] } trait Functor[F[_]] extends GenericFunctor[Function, Function, F] { final def fmap[A, B](as: F[A])(f: A => B): F[B] = fmap(f)(as) } Clearly this means Functors can be used with other higher

问题 There is a nice Free Alternative in the great free package, which lifts a Functor to a left-distributive Alternative. That is, the claim is that: runAlt :: Alternative g => (forall x. f x -> g x) -> Alt f a -> g a is an Alternative homomorphism , with liftAlt . And, indeed, it is one, but only for left-distributive Alternative instances. Of course, in reality, very few Alternative instances are actually left-distributive. Most of the alternative instances that actually matter (parsers, MaybeT

问题 According to the famous paper Idioms are oblivious, arrows are meticulous, monads are promiscuous, the expressive power of arrows (without any additional typeclasses) should be somewhere strictly between applicative functors and monads: monads are equivalent to ArrowApply , and Applicative should be equivalent to something the paper calls "static arrows". However, it is not clear to me what restriction this "static"-ness means. Playing around with the three typeclasses in question, I was able

问题 According to the famous paper Idioms are oblivious, arrows are meticulous, monads are promiscuous, the expressive power of arrows (without any additional typeclasses) should be somewhere strictly between applicative functors and monads: monads are equivalent to ArrowApply , and Applicative should be equivalent to something the paper calls "static arrows". However, it is not clear to me what restriction this "static"-ness means. Playing around with the three typeclasses in question, I was able