态射、乘积、余积运算符优先级和结合性
Morphism, product, coproduct operator precedence and associativity
我正在编写一个解析器来解析一种简单的函数式玩具语言。
我在 运算符优先级 和 关联性 的 态射 、 乘积方面遇到了困难 和 余积 运算符。
我的玩具语言看起来 微小 有点像 Haskell。上下文示例:
let point: (int, int) = (0, 0) // product
let either: (int | str) = "hello" // coproduct
let increment: int -> int = a -> a + 1 // morphism
在解析类型时,我很难决定二进制中缀 态射 运算符 ->
应该是右结合还是左结合。如果我没记错的话,二进制中缀 functional composition operator .
是右结合的;也许这个运算符也一样?
int -> int -> int
应该解析为(int -> int) -> int
还是int -> (int -> int)
?
此运算符相对于二进制中缀 product 和 coproduct 运算符的优先级是多少(,
,|
)?
现在我有以下优先级(从高到低):
- 态射
- 产品
- 余积
这意味着在没有圆括号 (...)
的情况下,语言的行为如下:
产品 str, int -> int, str
被解析为 str, (int -> int), str
。
余积int | str -> int | str
具有相同的效果int | (str -> int) | str
.
str, int -> int | int
被解析为 (str, (int -> int) | int)
.
这是正确的还是我做错了什么?
这是一个有效问题的原因
I apologise but I'm avoiding getting flagged when this is a good question because:
- 我找不到解释这三个运算符如何相互关联的资源,以何种方式、优先级和结合性。
- 我无法将问题拆分成更小的问题,因为其中一个问题的一般行为发生变化会显着影响其他问题。
- 这是一个与编程相关的问题,因为它是关于编程语言的抽象语法树生成。
- 我在这里没有找到关于这些运算符的类似问题(也许我使用了错误的关键字)。
- 其他人在制作解析器时可能会遇到同样的问题。
- 它看起来不像是基于我的意见。
所以请考虑留下评论告诉我应该如何改进这个问题。
Haskell 中的关联规则是有充分理由的。他们遵循 currying adjunction 的想法。两个参数的函数与返回函数的函数同构。所以 (a, b) -> c
被柯里化为 a -> (b -> c)
。这就是为什么 a->b->c
被解释为返回函数的函数而不是 (a->b)->c
的原因,后者将是一个将函数作为参数的函数。相反,对于函数应用程序,我们将 f g h
解析为 f
,使用两个参数 f
和 g
。因此函数应用程序是左关联的,(f g) h
:f
作用于 g
产生一个随后作用于 h
的函数。至于乘积和副积,它们只是按照通常的优先规则被视为乘法和加法。顺便说一下,a->b
对应于指数 b
的 a
次方,就结合律而言,这也是有意义的。
我正在编写一个解析器来解析一种简单的函数式玩具语言。
我在 运算符优先级 和 关联性 的 态射 、 乘积方面遇到了困难 和 余积 运算符。
我的玩具语言看起来 微小 有点像 Haskell。上下文示例:
let point: (int, int) = (0, 0) // product
let either: (int | str) = "hello" // coproduct
let increment: int -> int = a -> a + 1 // morphism
在解析类型时,我很难决定二进制中缀 态射 运算符 ->
应该是右结合还是左结合。如果我没记错的话,二进制中缀 functional composition operator .
是右结合的;也许这个运算符也一样?
int -> int -> int
应该解析为(int -> int) -> int
还是int -> (int -> int)
?
此运算符相对于二进制中缀 product 和 coproduct 运算符的优先级是多少(,
,|
)?
现在我有以下优先级(从高到低):
- 态射
- 产品
- 余积
这意味着在没有圆括号 (...)
的情况下,语言的行为如下:
产品 str, int -> int, str
被解析为 str, (int -> int), str
。
余积int | str -> int | str
具有相同的效果int | (str -> int) | str
.
str, int -> int | int
被解析为 (str, (int -> int) | int)
.
这是正确的还是我做错了什么?
这是一个有效问题的原因
I apologise but I'm avoiding getting flagged when this is a good question because:
- 我找不到解释这三个运算符如何相互关联的资源,以何种方式、优先级和结合性。
- 我无法将问题拆分成更小的问题,因为其中一个问题的一般行为发生变化会显着影响其他问题。
- 这是一个与编程相关的问题,因为它是关于编程语言的抽象语法树生成。
- 我在这里没有找到关于这些运算符的类似问题(也许我使用了错误的关键字)。
- 其他人在制作解析器时可能会遇到同样的问题。
- 它看起来不像是基于我的意见。
所以请考虑留下评论告诉我应该如何改进这个问题。
Haskell 中的关联规则是有充分理由的。他们遵循 currying adjunction 的想法。两个参数的函数与返回函数的函数同构。所以 (a, b) -> c
被柯里化为 a -> (b -> c)
。这就是为什么 a->b->c
被解释为返回函数的函数而不是 (a->b)->c
的原因,后者将是一个将函数作为参数的函数。相反,对于函数应用程序,我们将 f g h
解析为 f
,使用两个参数 f
和 g
。因此函数应用程序是左关联的,(f g) h
:f
作用于 g
产生一个随后作用于 h
的函数。至于乘积和副积,它们只是按照通常的优先规则被视为乘法和加法。顺便说一下,a->b
对应于指数 b
的 a
次方,就结合律而言,这也是有意义的。