用invmap代替fmap和contramap的推导

Question

注：目前的问题是后续这一块。 丹尼尔·瓦格纳( Daniel Wagner) 给出了很好的回答。

我试图弄清楚如何为给定类型的* -> *派生自然地图。 natmap是F的自然映射，如果它等于：

• fmap :: (a -> b) -> F a -> F b在协变F情况下，
• contramap :: (b -> a) -> F a -> F b在逆变F情况下，
• invmap :: (a -> b) -> (b -> a) -> F a -> F b在不变F情况下，
• 或phantom :: F a -> F b在 phantom F情况下。

总而言之， Daniel Wagner提出了一种算法，如果给定的函子是协变的或失败，则该算法会导出fmap 。 contramap和invmap也可以这样做。 他们实现了fmap和contramap ：

-- COVARIANT

fmap @(F + F') f (Left x) = Left (fmap @F f x)
fmap @(F + F') f (Right x) = Right (fmap @F' f x)
fmap @(F * F') f (x, y) = (fmap @F f x, fmap @F f y)
fmap @(Id) f x = f x
fmap @(Const X) f x = x
fmap @(F -> F') f x = fmap @F' f . x . contramap @F f

fmap @(F . F') f x = fmap @F (fmap @F' f) x
-- OR
fmap @(F . F') f x = contramap @F (contramap @F' f) x

-- CONTRAVARIANT

contramap @(F + F') f (Left x) = Left (contramap @F f x)
contramap @(F + F') f (Right x) = Right (contramap @F' f x)
contramap @(F * F') f (x, y) = (contramap @F f x, contramap @F' f y)
-- contramap @(Id) fails
contramap @(Const X) f x = x
contramap @(F -> F') f x = contramap @F' f . x . fmap @F f

contramap @(F . F') f x = contramap @F (fmap @F' f) x
-- OR
contramap @(F . F') f x = fmap @F (contramap @F' f) x

丹尼尔瓦格纳的回答让我思考。 它必须是可取代三个算法（其派生fmap ， contramap和invmap ）与单个算法，该算法导出invmap 。 例如：我们为data F a = F (a, a)推导出invmap并且在这样做的同时发现F是协变的。 因此，我们可以为F定义fmap f = invmap f undefined 。 反之亦然，对于data F' = F' ((a, a) -> Int) ： contramap g = invmap undefined g 。

invmap是invmap派生的？

基本上，我们调整 Daniel Wagner 的算法：

{- 1 -} invmap @(F + F') f g (Left x) = Left (invmap @F f g x)
{- 2 -} invmap @(F + F') f g (Right x) = Right (invmap @F' f g x)
{- 3 -} invmap @(F * F') f g (x, y) = (invmap @F f g x, invmap @F' f g y)
{- 4 -} invmap @(F -> F') f g x = invmap @F' f g . x . invmap @F g f

{- 5 -} invmap @(F . F') f g x = invmap @F (invmap @F' f g) (invmap @F' g f) x

{- 6 -} invmap @(Id) f g x = f x
{- 7 -} invmap @(Const X) f x = x

关于上面的一些行的一些评论：

⁵这个想法是在invmap @F (invmap @F' ab) (invmap @F' cd) ：

• a过程协变在位置F其中出现在协变位置F' ，
• b处理在逆变位置F其出现在协变位置F' ，
• c处理F中出现在F'中逆变位置的协变位置，
• d处理在逆变位置F其出现在逆变位置F' 。

IE。 a和d处理协变位置，而b和c处理逆变位置。 因此， a = d = f ； b = c = g 。

⁶ Id Leafcase 对于逆变函子确实失败了，因为当contramap g时， undefined被放在f的位置。 Dually： Id Leafcase 是唯一一个直接将f用于协变函子的方法。

为什么有效？

我认为这个算法可以工作的原因很简单： invmap实际上不必直接使用它的每个参数。 此外，当我们尝试将协变处理器用于逆变函子（即运行contramap @Id gx ）时，我们会得到一个错误（因为协变处理器是undefined ）。

基本上，我的想法来自执行fmap和contramap来讲invmap ，就像phantom是在以下方面实现fmap和contramap 。

为什么有趣？

分支会产生一些过热。 例如：

contramap @(F . F') f x = contramap @F (fmap @F' f) x
-- OR
contramap @(F . F') f x = fmap @F (contramap @F' f) x

除非F和F'是幻像，否则在检查F和F'的整个结构后，其中一种情况会失败。 人们可能会声称，从两个中选择一个并没有真正归类为过热，并且可以原谅以保持可读性。 但是使用invmap事情变得非常难看。 我认为以下每种情况都有7个子情况： F -> F' 、 F + F' 、 F * F' 。 这样的代码似乎效率很低。

所有这些子案例都是由我们对方差的假设产生的。 当我们停止仅派生invmap ，分支就会消失。

问题

这个算法会产生合法的自然地图吗？ 我认为我们无法证明fmap f = invmap f undefined在合法情况下fmap f = invmap f undefined 。 相反，我们依赖于这样一个事实，即当我们遇到一个逆变位置（对于逆变相同）时，我们运行逆变处理器，这就是上面算法中的情况。

---

PS有些人认为Invariant接口不如Profunctor s，应该避免。 但是，如果我的算法确实是正确的，我认为这对于这样的类来说是一个很好的用途。