[Haskell-cafe] Bing/Copilot Answer: "->", has highest precedence for type construction but in general has nuanced precedence order

[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/item582390761
<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-precedence-in-haskell
> 2
https://www.haskellsos.com/basics/what-order-would-haskell-evaluate-2-operands-of-the-same-precedence/
> 3 https://devhubby.com/thread/what-is-the-precedence-of-and-in-haskell
> 4
https://studentprojectcode.com/blog/how-to-change-precedence-of-constructor-in-haskell
> 5
https://stackoverflow.com/questions/3125395/haskell-operator-vs-function-precedence
> 6
https://stackoverflow.com/questions/56202894/what-is-the-precedence-of-and-in-haskell
> 7
https://codereview.stackexchange.com/questions/120900/expression-parser-in-haskell-using-operator-precedence-table
> 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/item582390849

I wonder how people would rate Bing's answer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20240316/c26fbed6/attachment.html>