Hlint 建议：使用 uncurry答案

【问题标题】：Hlint suggestion: use uncurryHlint 建议：使用 uncurry
【发布时间】：2018-03-15 12:40:15
【问题描述】：

我有这行代码：

map (\(u,v) -> flatTorus n u v) gridUV

Hlint 建议我用

替换它

map (uncurry (flatTorus n)) gridUV

这个建议的动机是什么？它只是为了简短，还是其他（性能）？因为虽然它更长，但我发现第一个代码更容易阅读。

事实上，我的问题更笼统，因为这只是一个例子：Hlint 的建议通常只是基于短促动机还是建议背后有其他改进？

【问题讨论】：

我猜想更具可读性：如果你知道uncurry 做了什么，那么人们就不必考虑正在发生的事情了。我还认为hlint 建议map (uncurry (flatTorus n)) gridUV（带有一对额外的括号）。
我认为hlint 的建议以简洁性和可读性为指导。他们中的一些人可能会在社区中找到一个强有力的协议。其他的，比如这个，没有那么多。就个人而言，我发现第二个代码并不比第一个好多少。我会说它们几乎是等价的。也许hlint 也应该重视它的建议。
@StéphaneLaurent：很好地使用x!!0 和head x 都不是很优雅。您最好为此使用模式匹配，因为不能保证列表具有元素。事实上head、tail、(!!)和length是应该避免的函数。
@StéphaneLaurent 我会写let [a,b,c] = x in Vertex3 a b c
@Li-yaoXia：嗯，我认为你必须保留一个（可能是空的尾巴）。但你可以喜欢：f (x0:x1:x2:_) = Vertex x0 x1 x2; f _ = <something else>

【解决方案1】：

我认为 Hlint 更喜欢使用 uncurry，因为它为您提供了回调的不变表示。 Lambda 表达式天生对表示很敏感，因为

\(u, v) -> flatTorus n u v

等价于

\(x, y) -> flatTorus n x y

即使它们在文字上有所不同。

使用uncurry 可以让读者摆脱脑中进行 alpha 等价的认知负担（例如，认识到上述两个表达式是相同的），但随后又让他们背负着必须记住组合子词汇的认知负担.归根结底，这是一个品味问题。

【讨论】：

【解决方案2】：

这些实际上并不完全等价。

(\(x, y) -> (,) x y) undefined = undefined
uncurry (,) undefined = (undefined, undefined)

您是否应该接受任何建议来使用uncurry 与一粒盐。想想这种额外的懒惰是否会有所帮助、伤害或没有影响。

【讨论】：