Numeric vs. relative precedences of infix operators
Is it widely accepted that the precedence of infix operators is defined by numbers? The numbers look arbitrary to me and it is not possible to introduce infix operators with interim precedences. What about defining relations such as "(*) has precedence over (+)"? The compiler could construct a topographically ordered graph from these relations. This way it would also be possible that from two infix operators none has precedence over the other (although the have not the _same_ precedence), thus the sub-expressions with these operators must be enclosed in parentheses.
Henning Thielemann writes:
Is it widely accepted that the precedence of infix operators is defined by numbers? The numbers look arbitrary to me and it is not possible to introduce infix operators with interim precedences. What about defining relations such as "(*) has precedence over (+)"? The compiler could construct a topographically ordered graph from these relations.
"Widely accepted" is a widely accepted relativism... I am also annoyed by the precedences 0,1,2, ...,9, etc. Why not 10, 20, 30,... ?? When I taught compilation, I suggested to use pairs (lprec,rprec) to denote simultaneously the precedence and the associativity. The parsing becomes quite homogeneous. (This is a very old idea, not mine, obviously...) Of course, there is a necessity to define the non-associativity as well... Some partial ordering is needed. But in this style it is even possible to declare "bracketing" operators. If the lprec of the second is equal to lprec of the first, then *both* operators are reduced. Parentheses become operators as all others... Jerzy Karczmarczuk
G'day all. Quoting karczma@info.unicaen.fr:
"Widely accepted" is a widely accepted relativism... I am also annoyed by the precedences 0,1,2, ...,9, etc.
Why not 10, 20, 30,... ??
I _think_ we had this back around Haskell 1.1 (which I never used, but early Gofers also had it). Moreover, operators could also have arbitrary "fixity" (prefix, infix, postfix). I'm not sure why this feature was dropped, but it's probably to do with the fact that when you do this, the language no longer has a managable LR grammar. Cheers, Andrew Bromage
On Mon, 28 Feb 2005 ajb@spamcop.net wrote:
G'day all.
Quoting karczma@info.unicaen.fr:
"Widely accepted" is a widely accepted relativism... I am also annoyed by the precedences 0,1,2, ...,9, etc.
Why not 10, 20, 30,... ??
I _think_ we had this back around Haskell 1.1 (which I never used, but early Gofers also had it). Moreover, operators could also have arbitrary "fixity" (prefix, infix, postfix).
I'm not sure why this feature was dropped,
Because of readability I don't plead for arbitrary "fixities", I think the current solution of infix operators in Haskell is enough. There is really no advantage of "n !" over "faculty n".
G'day all.
Quoting Henning Thielemann
Because of readability I don't plead for arbitrary "fixities", I think the current solution of infix operators in Haskell is enough. There is really no advantage of "n !" over "faculty n".
Me neither, but there is a (semi-weak) argument for arbitrary precedences. Cheers, Andrew Bromage
On Tuesday 01 March 2005 15:28, Henning Thielemann wrote:
On Mon, 28 Feb 2005 ajb@spamcop.net wrote:
G'day all.
Quoting karczma@info.unicaen.fr:
"Widely accepted" is a widely accepted relativism... I am also annoyed by the precedences 0,1,2, ...,9, etc.
Why not 10, 20, 30,... ??
I _think_ we had this back around Haskell 1.1 (which I never used, but early Gofers also had it). Moreover, operators could also have arbitrary "fixity" (prefix, infix, postfix).
I'm not sure why this feature was dropped,
Because of readability I don't plead for arbitrary "fixities", I think the current solution of infix operators in Haskell is enough. There is really no advantage of "n !" over "faculty n".
There is a good argument for 'distfix' i.e. bracketing operators, IMO. You could define your own if_then_else: `if cond `then` truebranch `else` falsebranch end` (Syntax, terminology, and example stolen from "Macros and Preprocessing in Haskell", (1999) by Keith Wansbrough, see http://citeseer.ist.psu.edu/wansbrough99macros.html) Ben
On Wed, 2 Mar 2005, Benjamin Franksen wrote:
There is a good argument for 'distfix' i.e. bracketing operators, IMO. You could define your own if_then_else:
`if cond `then` truebranch `else` falsebranch end`
I would be more happy with if :: Bool -> a -> a -> a if True x _ = x if False _ y = y than with parentheses redefinitions as () and [] in C++.
participants (4)
-
ajb＠spamcop.net -
Benjamin Franksen -
Henning Thielemann -
karczma＠info.unicaen.fr