键入的FP：元组参数和可压缩参数 [英] Typed FP: Tuple Arguments and Curriable Arguments

问题描述

在像Standard ML，F＃，OCaml和Haskell这样的静态类型函数式编程语言中，函数通常会以参数彼此分开的方式编写，并且只需通过空格写入函数名称即可：

  let add ab = 
a + b 
  

这里的类型是 int - >（int - > int），即一个接受int并返回一个函数的函数需要和int，并最终返回一个int。因此，可以使用currying。

也可以定义一个类似的函数，它将一个元组作为参数：

  let add（a，b）= 
a + b 
  

在这种情况下，类型变为（int * int） - > int 。

从语言设计的观点，是否有任何理由不能简单地在类型代数中识别这两种类型模式？换句话说，（a * b） - > c减少到a - >（b - > c），使得两种变体都可以同样容易地被咖喱咖啡。

我假设这个问题必须在我提到的四个语言这样的语言被设计出来的时候出现。那么，是否有人知道有任何理由或研究指出为什么所有这四种语言都选择不统一这两种类型的模式？ 解决方案

我认为今天的共识是通过currying（ a - > b - > c 表单）来处理多个参数，并保留元组因为当你真正想要元组类型的值（在列表等等）。这个共识是每一个静态类型函数语言所遵守的，因为标准ML（纯粹作为惯例）使用元组来获取多个参数。

为什么会这样所以？标准ML是这些语言中最古老的语言，当人们第一次写ML编译器时，并不知道如何有效地处理有趣的争论。 （问题的根源在于任何 curried函数可以 部分地被其他一些尚未见过的代码部分应用，并且必须用）。由于设计了标准ML，编译器有所改进，您可以阅读 Simon Marlow和Simon Peyton Jones的优秀论文。

LISP，这是它们最老的功能语言，它具有一种对currying和部分应用非常不友好的具体语法。 Hrmph。

In statically typed functional programming languages, like Standard ML, F#, OCaml and Haskell, a function will usually be written with the parameters separated from each other and from the function name simply by whitespace:

let add a b =
    a + b

The type here being "int -> (int -> int)", i.e. a function that takes an int and returns a function which its turn takes and int and which finally returns an int. Thus currying becomes possible.

It's also possible to define a similar function that takes a tuple as an argument:

let add(a, b) =
    a + b

The type becomes "(int * int) -> int" in this case.

From the point of view of language design, is there any reason why one could not simply identify these two type patterns in the type algebra? In other words, so that "(a * b) -> c" reduces to "a -> (b -> c)", allowing both variants to be curried with equal ease.

I assume this question must have cropped up when languages like the four I mentioned were designed. So does anyone know any reason or research indicating why all four of these languages chose not to "unify" these two type patterns?

解决方案

I think the consensus today is to handle multiple arguments by currying (the a -> b -> c form) and to reserve tuples for when you genuinely want values of tuple type (in lists and so on). This consensus is respected by every statically typed functional language since Standard ML, which (purely as a matter of convention) uses tuples for functions that take multiple arguments.

Why is this so? Standard ML is the oldest of these languages, and when people were first writing ML compilers, it was not known how to handle curried arguments efficiently. (At the root of the problem is the fact that any curried function could be partially applied by some other code you haven't seen yet, and you have to compile it with that possibility in mind.) Since Standard ML was designed, compilers have improved, and you can read about the state of the art in an excellent paper by Simon Marlow and Simon Peyton Jones.

LISP, which is the oldest functional language of them all, has a concrete syntax which is extremely unfriendly to currying and partial application. Hrmph.

这篇关于键入的FP：元组参数和可压缩参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！