为什么`(\ xy - > x + y)@Integer`失败,但`(+)@ Integer`成功了?

Ign*_*rov 5 haskell types

考虑:

? :type (+) @Integer
(+) @Integer :: Integer -> Integer -> Integer




? :type (\x y -> x + y) @Integer
...
...error...
...Cannot apply expression...
...

? f = (+)
? :type f @Integer
...
...error...
...Cannot apply expression...
...

? g = \x y -> x + y
? :type g @Integer
...
...error...
...Cannot apply expression...
...

? h x y = x + y
? :type h @Integer
...
...error...
...Cannot apply expression...
...
Run Code Online (Sandbox Code Playgroud)

同时:

? :type (+)
... :: Num a => a -> a -> a

? :type (\x y -> x + y)
... :: Num a => a -> a -> a

? :type f
... :: Num a => a -> a -> a

? :type g
... :: Num a => a -> a -> a

? :type h
... :: Num a => a -> a -> a
Run Code Online (Sandbox Code Playgroud)

因此,即使这些对象的类型没有区别,它们看起来与类型应用程序不同.

  • 为什么?
  • 我错过了一些明显的东西吗
  • 这是一个错误吗?
  • 这是一个功能吗?
  • 这种语言设计不好吗?
  • 这是伟大的语言设计吗?

Tho*_*son 7

在大多数情况下,类型应用程序只能在存在显式类型签名时应用.引用GHC文件:

如果该函数是标识符(通用情况),则仅当标识符已被赋予类型签名时才认为其类型是已知的.

为什么?

我猜这种设计是存在的,因为当你有明确的签名时,类型变量的顺序是很好的定义.

我错过了一些明显的东西吗

由您决定以上是多么明显.您可以深入思考文档和设计讨论,以查看对话的演变但是参数的顺序,当类型应用程序只能通过命令严格完成时,似乎跳出来作为一个问题.

这是一个错误吗?

我不相信.也许对于lambda案.

这是一个功能吗?

一致性良好的特征.

这种语言设计不好吗?这是伟大的语言设计吗?

也许更好的语言设计是允许简单的例子,例如你的,在没有可能的歧义时工作(类型参数顺序是隐含的,因为只有一个类型参数).