Bing/Copilot Answer: "->", has highest precedence for type construction but in general has nuanced precedence order
I was asking Bing Copilot questions to better understand the order of precedence in: sequence :: Monad m => [m a] -> m [a] sequence = foldr mcons (return []) where mcons p q = p >>= \x -> q >>= \y -> return (x:y) I noticed that for evaluation (e.g. binding variables to real world data), the left most "->" seems to have it's lambda variables bound first but with regards parsing this left most "->" seems to be the least deeply nested which in a strick language would suggest a low order of precedence. In the summary part of bing's answer, bing actually said that "->" has the highest order of precedence but if you read the whole answer you see it is only for type construction where Bing specifically made claims of the order of precedence and in the other case (parsing & fixity), bing said that the fixity of "->" is not defined in the Haskell 98 report, and nuanced it by saying that the parsing rules depend on both fixity and associativity. Here is my Question to bing:
Related to the above there seems to be ambiguity in the phrase “order of precedence here”. With regards to evaluation the order -- in the case of mcons (shown above) -- the “->” operator seems to get bound first, with real world data. This suggests a higher order of precedence for “->” than the other operators. However, with regards to parsing the operator “->” is associated with less deeply nested brackets, which in a strict language would suggest a lower order of precedence, or equivalently in Haskell lingual, a lower fixity. Fixity is defined in Talb 2 at but this table doesn’t give the fixity for “->”. www.haskell.org/onlinereport/decls.html#nested
*https://www.pearltrees.com/s243a/question-evaluation-questions/id76447605/it... https://www.pearltrees.com/s243a/question-evaluation-questions/id76447605/it... * and here is bing's answer:
You’ve raised an interesting point regarding the perceived ambiguity in the phrase “order of precedence” when it comes to the -> operator in Haskell. Let’s delve into this topic and clarify the nuances.
*1. Operator Precedence and Associativity:> * *In Haskell, operator precedence determines
the order in which operators are evaluated. It ensures that expressions are parsed unambiguously. * The associativity of an operator determines whether it is evaluated from left to right (left-associative) or from right to left (right-associative). * The -> operator (function type constructor) has a specific precedence and associativity.
*> 2. Function Type Constructor (->) Precedence:**> * *The -> operator has the *highest precedence* among
all operators in Haskell. It is used to specify a function’s type signature, such as Int -> Int -> Float. * Being right-associative, it means that function types associate from right to left. For example, Int -> Int -> Float is equivalent to Int -> (Int -> Float).
*3. Parsing and Fixity:**> * *When parsing expressions, Haskell follows specific
rules for each operator, including the -> operator. * The compiler determines how to group expressions based on the fixity (precedence and associativity) of operators. * Fixity declarations allow you to control how operators are parsed. *Unfortunately, the Haskell 98 Report does not explicitly list the fixity of the -> operator.
*4. Custom Operators and Readability:**> * *Custom operators (including symbolic ones)
can indeed decrease readability and maintainability. * When encountering unfamiliar operators, it’s challenging to deduce their meaning solely from their names. * The arbitrary-looking names lack hints for understanding their purpose, especially for newcomers. 5. *Using $ to Clarify Expressions:**> * *The $ operator is defined with very low precedence. * Writing f $ x is equivalent to f x, but it helps avoid parentheses. * By using $, you can explicitly indicate the evaluation order without relying on operator precedence.
*6. Conclusion:**> * *While the -> operator has the highest precedence,
its behavior is influenced by associativity and context. * Fixity declarations (such as infixr 0 ->) can help control how operators are parsed. * Understanding operator behavior and using $ judiciously can lead to more idiomatic and maintainable code.
In summary, the -> operator’s precedence is indeed high, but its behavior is nuanced due to associativity and parsing rules. Fixity declarations and careful usage of operators contribute to code clarity.
For more details, refer to the Haskell 98 Report.
Feel free to ask if you have further questions or need additional clarification! 😊 Learn more 1 https://stackoverflow.com/questions/23553139/operator-and-function-precedenc... 2 https://www.haskellsos.com/basics/what-order-would-haskell-evaluate-2-operan... 3 https://devhubby.com/thread/what-is-the-precedence-of-and-in-haskell 4 https://studentprojectcode.com/blog/how-to-change-precedence-of-constructor-... 5 https://stackoverflow.com/questions/3125395/haskell-operator-vs-function-pre... 6 https://stackoverflow.com/questions/56202894/what-is-the-precedence-of-and-i... 7 https://codereview.stackexchange.com/questions/120900/expression-parser-in-h... 8 https://kowainik.github.io/posts/fixity 9 https://devtut.github.io/haskell/infix-operators.html 10 https://www.haskell.org/onlinereport/decls.html https://sl.bing.net/gHzlncNjtLw https://www.pearltrees.com/s243a/question-evaluation-questions/id76447605/it...
I wonder how people would rate Bing's answer.
I think this is just a case of confusing unrelated concepts that use the same symbol. There is an operator named -> (for forming function types), but that's not what the exact same character sequence -> means in lambda syntax. The lambda syntax is roughly \args -> expr. The arrow there is more like a keyword than an operator; it doesn't have precedence, it just separates parts of a code structure. Much like the `=` in a function or type definitions. The parsing rule for lambas is a bit weird, because there is deep ambiguity in how much of the code following the -> should be taken as part of the lamba's body. The rule that resolves the ambiguity is that the lamba's body extends as far as it can without causing a parsing error. So when you have multiple lambas occurring near each other, as in your example, usually the latter ones are inside the body of the first one, unless there are parentheses or the end of an aligned block or something else to force a specific place where the first one ends. But this isn't really the operator precedence system at work, it's the specific parsing rule for lambas syntax. Bing Copilot is giving you misleading information because when you ask about the precedence of ->, the only interpretation that can really make sense of that question is if you're talking about it as an operator, and it then gets distracted talking about operator precedence in general (and the way fixity declarations mean you can't necessarily tell an operator's precedence without the full context). But in lamba syntax (and case syntax, etc) the arrow simply isn't an operator, so none of this is really relevant. Ben 17 Mar 2024, 9:58 am by johns243a@gmail.com:
I was asking Bing Copilot questions to better understand the order of precedence in:
sequence :: Monad m => [m a] -> m [a] sequence = foldr mcons (return []) where mcons p q = p >>= \x -> q >>= \y -> return (x:y) I noticed that for evaluation (e.g. binding variables to real world data), the left most "->" seems to have it's lambda variables bound first but with regards parsing this left most "->" seems to be the least deeply nested which in a strick language would suggest a low order of precedence. In the summary part of bing's answer, bing actually said that "->" has the highest order of precedence but if you read the whole answer you see it is only for type construction where Bing specifically made claims of the order of precedence and in the other case (parsing & fixity), bing said that the fixity of "->" is not defined in the Haskell 98 report, and nuanced it by saying that the parsing rules depend on both fixity and associativity.
Here is my Question to bing:
Related to the above there seems to be ambiguity in the phrase “order of precedence here”. With regards to evaluation the order -- in the case of mcons (shown above) -- the “->” operator seems to get bound first, with real world data. This suggests a higher order of precedence for “->” than the other operators. However, with regards to parsing the operator “->” is associated with less deeply nested brackets, which in a strict language would suggest a lower order of precedence, or equivalently in Haskell lingual, a lower fixity. Fixity is defined in Talb 2 at but this table doesn’t give the fixity for “->”. > www.haskell.org/onlinereport/decls.html#nested http://www.haskell.org/onlinereport/decls.html#nested> https://www.pearltrees.com/s243a/question-evaluation-questions/id76447605/item582390761> and here is bing's answer:
You’ve raised an interesting point regarding the perceived ambiguity in the phrase “order of precedence” when it comes to the -> operator in Haskell. Let’s delve into this topic and clarify the nuances. > 1. Operator Precedence and Associativity: * > In Haskell, operator precedence determines> > the order in which operators are evaluated. It ensures that expressions are parsed unambiguously. * The associativity of an operator determines whether it is evaluated from left to right (left-associative) or from right to left (right-associative). * The -> operator (function type constructor) has a specific precedence and associativity. 2. Function Type Constructor (->) Precedence: * > The -> operator has the > highest precedence> among> > all operators in Haskell. It is used to specify a function’s type signature, such as Int -> Int -> Float. * Being right-associative, it means that function types associate from right to left. For example, Int -> Int -> Float is equivalent to Int -> (Int -> Float). > 3. Parsing and Fixity: * > When parsing expressions, Haskell follows specific> > rules for each operator, including the -> operator. * The compiler determines how to group expressions based on the fixity (precedence and associativity) of operators. * Fixity declarations allow you to control how operators are parsed. *Unfortunately, the Haskell 98 Report does not explicitly list the fixity of the -> operator. > 4. Custom Operators and Readability: * > Custom operators (including symbolic ones)> > can indeed decrease readability and maintainability. * When encountering unfamiliar operators, it’s challenging to deduce their meaning solely from their names. * The arbitrary-looking names lack hints for understanding their purpose, especially for newcomers. 5. > Using $ to Clarify Expressions: * > The $ operator is defined with very low precedence.> > * Writing f $ x is equivalent to f x, but it helps avoid parentheses. * By using $, you can explicitly indicate the evaluation order without relying on operator precedence. > 6. Conclusion: * > While the -> operator has the highest precedence,> > its behavior is influenced by associativity and context. * Fixity declarations (such as infixr 0 ->) can help control how operators are parsed. * Understanding operator behavior and using $ judiciously can lead to more idiomatic and maintainable code.
In summary, the -> operator’s precedence is indeed high, but its behavior is nuanced due to associativity and parsing rules. Fixity declarations and careful usage of operators contribute to code clarity.
For more details, refer to the > Haskell 98 Report> .
Feel free to ask if you have further questions or need additional clarification! 😊 Learn more > 1 > https://stackoverflow.com/questions/23553139/operator-and-function-precedenc... 2 > https://www.haskellsos.com/basics/what-order-would-haskell-evaluate-2-operan... 3 > https://devhubby.com/thread/what-is-the-precedence-of-and-in-haskell 4 > https://studentprojectcode.com/blog/how-to-change-precedence-of-constructor-... 5 > https://stackoverflow.com/questions/3125395/haskell-operator-vs-function-pre... 6 > https://stackoverflow.com/questions/56202894/what-is-the-precedence-of-and-i... 7 > https://codereview.stackexchange.com/questions/120900/expression-parser-in-h... 8 > https://kowainik.github.io/posts/fixity 9 > https://devtut.github.io/haskell/infix-operators.html 10 > https://www.haskell.org/onlinereport/decls.html
https://sl.bing.net/gHzlncNjtLw https://www.pearltrees.com/s243a/question-evaluation-questions/id76447605/it...
I wonder how people would rate Bing's answer.
On 16.03.24 23:57, John Creighton wrote:
In the summary part of bing's answer, bing actually said that "->" has the highest order of precedence but if you read the whole answer you see it is only for type construction where Bing specifically made claims of the order of precedence and in the other case (parsing & fixity), bing said that the fixity of "->" is not defined in the Haskell 98 report, and nuanced it by saying that the parsing rules depend on both fixity and associativity.
The thing with GPT AIs like what's currently hyped is that it's essentially just piecing together sentences on the basis of "in all the training data, what was the most likely follow-up word". IN particular, they do not follow any reasoning or do any semantic analysis whatsoever. This is great for writing speeches. It's also great for boilerplate code. It's bad for accuracy. It essentially depends on the quality of the training data, and since these GPT bots need humongous amounts of training, that's typically "just the Internet". (The companies behind these bots try to filter out nonsense, with a focus on avoiding public outcry, which tends to create even more humorous results.) Regards, Jo
Not all grammatical issues are operator precedence issues.
Why on earth would you ask Bing/Copilot about this rather than reading
the report?
That's like saying "Hey, there's a spring of fresh pure water just
over there, so I'll drink from this muddy puddle instead."
As others have remarked, there are two separate but essentially
related symbols -> , and one of them is a type constructor
that is rather like an operator, but the other is part of the syntax
of lambda expressions and is NOT an operator and so
does not have an operator precedence.
It is traditional in the lambda calculus, in order to reduce the
number of required parentheses, to parse
\x -> \y -> \z -> ... as \x -> (\y -> (\z -> ...)) with the lambda
expression extending as far to the right as possible and
as little to the left as necessary. (Which is not how infix operators work.)
As a type, x -> y -> z -> t is parsed as x -> (y -> (z -> t)) and
again this has traditionally not been anything to do
with operator precedence.
There are other things, like (,,) and [..], which can appear in both
types (as type constructors) and expressions.
On Sun, 17 Mar 2024 at 11:58, John Creighton
I was asking Bing Copilot questions to better understand the order of precedence in:
sequence :: Monad m => [m a] -> m [a] sequence = foldr mcons (return []) where mcons p q = p >>= \x -> q >>= \y -> return (x:y)
I noticed that for evaluation (e.g. binding variables to real world data), the left most "->" seems to have it's lambda variables bound first but with regards parsing this left most "->" seems to be the least deeply nested which in a strick language would suggest a low order of precedence. In the summary part of bing's answer, bing actually said that "->" has the highest order of precedence but if you read the whole answer you see it is only for type construction where Bing specifically made claims of the order of precedence and in the other case (parsing & fixity), bing said that the fixity of "->" is not defined in the Haskell 98 report, and nuanced it by saying that the parsing rules depend on both fixity and associativity.
Here is my Question to bing:
Related to the above there seems to be ambiguity in the phrase “order of precedence here”. With regards to evaluation the order -- in the case of mcons (shown above) -- the “->” operator seems to get bound first, with real world data. This suggests a higher order of precedence for “->” than the other operators. However, with regards to parsing the operator “->” is associated with less deeply nested brackets, which in a strict language would suggest a lower order of precedence, or equivalently in Haskell lingual, a lower fixity. Fixity is defined in Talb 2 at but this table doesn’t give the fixity for “->”. www.haskell.org/onlinereport/decls.html#nested https://www.pearltrees.com/s243a/question-evaluation-questions/id76447605/it...
and here is bing's answer:
You’ve raised an interesting point regarding the perceived ambiguity in the phrase “order of precedence” when it comes to the -> operator in Haskell. Let’s delve into this topic and clarify the nuances. 1. Operator Precedence and Associativity: * In Haskell, operator precedence determines the order in which operators are evaluated. It ensures that expressions are parsed unambiguously. * The associativity of an operator determines whether it is evaluated from left to right (left-associative) or from right to left (right-associative). * The -> operator (function type constructor) has a specific precedence and associativity. 2. Function Type Constructor (->) Precedence: * The -> operator has the highest precedence among all operators in Haskell. It is used to specify a function’s type signature, such as Int -> Int -> Float. * Being right-associative, it means that function types associate from right to left. For example, Int -> Int -> Float is equivalent to Int -> (Int -> Float). 3. Parsing and Fixity: * When parsing expressions, Haskell follows specific rules for each operator, including the -> operator. * The compiler determines how to group expressions based on the fixity (precedence and associativity) of operators. * Fixity declarations allow you to control how operators are parsed. *Unfortunately, the Haskell 98 Report does not explicitly list the fixity of the -> operator. 4. Custom Operators and Readability: * Custom operators (including symbolic ones) can indeed decrease readability and maintainability. * When encountering unfamiliar operators, it’s challenging to deduce their meaning solely from their names. * The arbitrary-looking names lack hints for understanding their purpose, especially for newcomers. 5. Using $ to Clarify Expressions: * The $ operator is defined with very low precedence. * Writing f $ x is equivalent to f x, but it helps avoid parentheses. * By using $, you can explicitly indicate the evaluation order without relying on operator precedence. 6. Conclusion: * While the -> operator has the highest precedence, its behavior is influenced by associativity and context. * Fixity declarations (such as infixr 0 ->) can help control how operators are parsed. * Understanding operator behavior and using $ judiciously can lead to more idiomatic and maintainable code.
In summary, the -> operator’s precedence is indeed high, but its behavior is nuanced due to associativity and parsing rules. Fixity declarations and careful usage of operators contribute to code clarity.
For more details, refer to the Haskell 98 Report.
Feel free to ask if you have further questions or need additional clarification! 😊 Learn more 1 https://stackoverflow.com/questions/23553139/operator-and-function-precedenc... 2 https://www.haskellsos.com/basics/what-order-would-haskell-evaluate-2-operan... 3 https://devhubby.com/thread/what-is-the-precedence-of-and-in-haskell 4 https://studentprojectcode.com/blog/how-to-change-precedence-of-constructor-... 5 https://stackoverflow.com/questions/3125395/haskell-operator-vs-function-pre... 6 https://stackoverflow.com/questions/56202894/what-is-the-precedence-of-and-i... 7 https://codereview.stackexchange.com/questions/120900/expression-parser-in-h... 8 https://kowainik.github.io/posts/fixity 9 https://devtut.github.io/haskell/infix-operators.html 10 https://www.haskell.org/onlinereport/decls.html
https://sl.bing.net/gHzlncNjtLw https://www.pearltrees.com/s243a/question-evaluation-questions/id76447605/it...
I wonder how people would rate Bing's answer. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
participants (4)
-
Ben -
jo＠durchholz.org -
John Creighton -
Richard O'Keefe