gpt4 book ai didi

haskell - `Alt` 类型类的仿函数分布规律是微不足道的吗?

转载 作者:行者123 更新时间:2023-12-02 02:13:01 25 4
gpt4 key购买 nike

我正在查看 the Alt typeclass 的法律,看起来像这样:

class Functor f => Alt f
where
(<!>) :: f a -> f a -> f a

其中一项法律是这样的:
<$> left-distributes over <!>:  f <$> (a <!> b) = (f <$> a) <!> (f <$> b)

更详细地说,这是:
fmap f $ (<!>) a b = (<!>) (fmap f a) (fmap f b)

假设我们 uncurry <!>操作,即我们假设这个类是这样写的:
class Functor f => Alt f
where
alt :: (f a, f a) -> f a

我们可以这样写一个组合器:

mapBoth :: Functor f => (a -> b) -> (f a, f a) -> (f b, f b)
mapBoth f = bimap (fmap f) (fmap f)

这代表 type Pair a = (a, a) 的组成具有给定仿函数的仿函数 f .所以它本身就是仿函数的态射映射。

有问题的法律现在可以这样写(不改变其含义):

fmap f . alt = alt . mapBoth f

请注意 mapBoth f只是申请 fmap f alt 的两个论点,如在法律的原始声明中。

这类似于要求 alt是仿函数 (f -, f -) 的自然变换到仿函数 f - .

但是, alt 的功能实际上是不可能的吗?的类型不是自然变换吗?如何编写 alt 的“糟糕”实现?那个类型检查,但会被法律拒绝?

最佳答案

虽然这不是其他答案和评论的共识,但这是 不是 “真实世界”Haskell 的自然属性。

这有助于编写非参数代码的开发人员知道何时应该添加约束以保持与将参数化视为理所当然的代码的兼容性。

行为不端的例子

{-# LANGUAGE GADTs #-}

data Badly a where
End :: a -> Badly a
Cons :: a -> Badly b -> Badly a

(<++>) :: Badly a -> Badly b -> Badly a
(End a) <++> r = Cons a r
(Cons a l) <++> r = Cons a (l <++> r)

instance Functor Badly where
fmap f (End a) = End (f a)
fmap f (Cons a r) = Cons (f a) r

instance Alt f where
(<!>) = (<++>)

关于haskell - `Alt` 类型类的仿函数分布规律是微不足道的吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/60381399/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com