双函子法与Arrow方法

Question

Bifunctor和Arrow方法之间有一些重叠：

class Bifunctor p where
  first :: (a -> a') -> p a b -> p a' b
  second :: (b -> b') -> p a b -> p a b'
  bimap :: (a -> a') -> (b -> b') -> p a b -> p a' b'

class Arrow (~~>) where
  ...
  first :: (a ~~> a') -> (a, b) ~~> (a', b)
  second :: (b ~~> b') -> (a, b) ~~> (a, b')
  (***) :: (a ~~> a') -> (b ~~> b') -> (a, b) ~~> (a', b')

Bifunctor类具有完全类似于Functor的规律。

Arrow类附带了许多法律、不同的法律以及关于(***)的一个有点神秘的警告：“注意，这通常不是函子。”令人惊讶的是(对我来说)关于(***)只有一条法律

first f >>> arr (id *** g) = arr (id *** g) >>> first f

Arrow (->)实例和Bifunctor (,)实例完全匹配，因此bimap @(,) = (***) @(->)。这有什么特殊意义吗？有没有什么有意义的假设

class Foo (~~>) p where
  biFoo :: (a ~~> a') -> (b ~~> b') -> p a b ~~> p a' b'

如果是这样的话，这是否承认功能依赖？

Answer 1

Arrow是一个(有点私生子化的) 笛卡尔闭范畴类的前身，或者说是一个最小的笛卡儿单面范畴。特别地，对于张量积为(,)和单位元()的单面范畴。

回想一下，张量乘积将单面范畴描述为双函子，所以Arrow和Bifunctor之间有联系。

事实上，***的法律比你所列出的要多，只是图书馆选择用first来制定这些法律。下面是这个类的等效定义：

class (Category k, Category k') => EnhancedCategory k k' where
  arr :: k a b -> k' a b
  -- arr id ≡ id
  -- arr (f . g) = arr f . arr g
class (EnhancedCategory (->) a) => Arrow a where
  (***) :: a b c -> a b' c' -> a (b,b') (c,c')
  -- (f***id) . (g***id) ≡ (f.g)***id
  -- (id***f) . (id***g) ≡ id***(f.g)
  -- arr fst . (f***id) ≡ f . arr fst
  -- arr snd . (id***g) ≡ g . arr snd
  -- ¿ arr swap . (f***g) ≡ (g***f) . arr swap ?
  -- ((f***g)***h) . assoc ≡ assoc . (f***(g***h))
  diag :: a b (b,b)

first :: Arrow a => a b c -> a (b,d) (c,d)
first f = f***id
second :: Arrow a => a b c -> a (d,b) (d,c)
second g = id***g
(&&&) :: Arrow a => a b c -> a b d -> a b (c,d)
f&&&g = (f***g) . diag

顺便说一句，还可以删除用于提升纯函数的arr，而只为超类提供专用方法fst、snd和assoc。Cartesian。这允许定义不包含任意Haskell函数的“箭头”类别；线性映射是一个重要的例子。

Answer 2

Arrow是等价物 to Strong + Category。

您可以选择不同的力量概念来获取Arrow。

class Category a => ArrowChoice a where
    arr :: (b -> c) -> a b c
    (+++) :: a b c -> a b' c' -> a (Either b b') (Either c c')

换句话说，笛卡尔闭范畴的张量乘积不一定就是(,)。任何张量乘积都有相应的强度概念，每一个都会给出相应的Arrow。

值得注意的是，许多终止函数都是Strong和Choice，因此您的Foo (基本上是在张量乘积p之上概括Strong )不具有功能依赖关系。

不幸的是，Control.Arrow模块在base中将层次结构搞混在一起(例如，它们的ArrowChoice将Arrow作为超类)。