4
$\begingroup$

Generally (perhaps always) in programming languages, unary operators have the highest precedence. In some langauges, such as Standard ML, one can dynamically change the precedence of binary operators at run time.

But what if we have a language where binary operators had higher precedence than unary ones? Do such languages exist? And how would we interpret certain cases? For example, let's say binary + had higher precedence than unary prefix @. In some cases this is obvious because it would mean that

@x+y

would parse as

@(x+y)

rather than

(@x)+y

BUT, how would we parse

x + @y

Would it be a syntax error (as in it cannot be parsed) or should it parse as x+(@y)? I don't mean for this to necessarily be an opinion question; I am more interested to know if any real programming languages exist with high-precedence binary operators, and if so, what do they do.

$\endgroup$
4
  • $\begingroup$ In Perl, the 'not' operator has lower precedence than +. The expression (false + not 1) evaluates just fine. $\endgroup$
    – mhum
    Commented Dec 10, 2013 at 20:12
  • $\begingroup$ Oh I completely forgot about the ultra-low precedence not, and, and or despite using them frequently in the past. I would accept that as an answer. I'm just so used to that Wirth-style of grammar writing where the operator precedence is built into parsing rules and that approach would seem to me to make syntax errors out of these things. I realize a language can parse with anything-goes rules but drew a blank as to which languages did this. Prolog and Perl are great answers. $\endgroup$
    – Ray Toal
    Commented Dec 10, 2013 at 23:51
  • 1
    $\begingroup$ No problem. In general, I'm not sure what the problem with parsing x + @y would be. I thought precedence only kicks in when there's an ambiguity in how an expression can be parsed. In this case, because @ is unary and + is binary, there is no ambiguity. $\endgroup$
    – mhum
    Commented Dec 11, 2013 at 0:00
  • $\begingroup$ If your grammar says EXP -> [not] TERM {'+' TERM} and TERM -> FACTOR {'*' FACTOR} and FACTOR -> id | numlit for example, then there would be no way to parse x + not y with this grammar. So the grammar would have to be written some other way, I would think. $\endgroup$
    – Ray Toal
    Commented Dec 11, 2013 at 0:31

2 Answers 2

1
$\begingroup$

In Perl, the 'not' operator has lower precedence than +. The expression (false + not 1) evaluates just fine.

$\endgroup$
0
$\begingroup$

OCaml also has if operator which has less precedence than, say, +:

1 + if true then 2 else 3 * 4

is interpreted by OCaml as:

1 + ( if true then 2 else (3 * 4) )

There if "covers" the (3 * 4) operation inside of itself.

Note that if then else in OCaml is not an if-statement, it's an if-expression, similar to C's ?: ternary operator. But if in Ocaml is a prefix operator, so it's similar to your @ example.

This phenomenon is well-known in the literature on parsing, see for example, Precedences in specifications and implementations of programming languages (1995) by Anna Aasa.

$\endgroup$
2
  • $\begingroup$ Where is the unary operator the above question is about? $\endgroup$
    – greybeard
    Commented Sep 25 at 5:13
  • $\begingroup$ @greybeard The operator @ in the question is just an example. In this answer, we show a real programming language with a prefix operator if, which has precedence below infix operators such as + and -. It behaves similarly to @ from the question, there is the same problem of a deep precedence conflict between unary and infix operators. $\endgroup$
    – shitpoet
    Commented Sep 25 at 15:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.