[Haskell-cafe] Numeric vs. relative precedences of infix operators

[Henning Thielemann]

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.

[k***@info.unicaen.fr]

Post by Henning Thielemann
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

[a***@spamcop.net]

G'day all.

Post by k***@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

[Henning Thielemann]

Post by a***@spamcop.net
G'day all.

Post by k***@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".

[a***@spamcop.net]

G'day all.

Post by 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

[Benjamin Franksen]

Post by Henning Thielemann

Post by a***@spamcop.net
G'day all.

Post by k***@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

[Henning Thielemann]

Post by Benjamin Franksen
There is a good argument for 'distfix' i.e. bracketing operators, IMO. You
`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++.