0

I saw this question and it got me wondering.

Ignoring the fact that pretty much all languages have to be backwards compatible, is there any reason we cannot use operators as both keywords and functions, depending on if it's immediately followed by a parenthesis? Would it make the grammar harder?

I'm thinking mostly of python, but also C-like languages.

Filip Haglund
  • 13,919
  • 13
  • 64
  • 113
  • The concepts `keyword` and `function` are orthogonal. That is, a function name may be a (reserved) keyword, or it may not. I'm not intimately familiar with Python but the way I read that other question it's not that `not(...)` isn't allowed or doesn't work but rather that it's misleading to the quick reader because it may be interpreted as a function call. – 500 - Internal Server Error Jul 31 '15 at 11:45

2 Answers2

1

Perl does something very similar to this, and the results are sometimes surprising. You'll find warnings about this in many Perl texts; for example, this one comes from the standard distributed Perl documentation (man perlfunc):

Any function in the list below may be used either with or without parentheses around its arguments. (The syntax descriptions omit the parentheses.) If you use parentheses, the simple but occasionally surprising rule is this: It looks like a function, therefore it is a function, and precedence doesn't matter. Otherwise it's a list operator or unary operator, and precedence does matter. Whitespace between the function and left parenthesis doesn't count, so sometimes you need to be careful:
     print 1+2+4;      # Prints 7.
     print(1+2) + 4;   # Prints 3.
     print (1+2)+4;    # Also prints 3!
     print +(1+2)+4;   # Prints 7.
     print ((1+2)+4);  # Prints 7.

An even more surprising case, which often bites newcomers:

 print
      (a % 7 == 0 || a % 7 == 1) ? "good" : "bad";

will print 0 or 1.

In short, it depends on your theory of parsing. Many people believe that parsing should be precise and predictable, even when that results in surprising parses (as in the Python example in the linked question, or even more famously, C++'s most vexing parse). Others lean towards Perl's "Do What I Mean" philosophy, even though the result -- as above -- is sometimes rather different from what the programmer actually meant.

C, C++ and Python all tend towards the "precise and predictable" philosophy, and they are unlikely to change now.

rici
  • 234,347
  • 28
  • 237
  • 341
0

Depending on the language, not() is not defined. If not() is not defined in some language, you can not use it. Why not() is not defined in some language? Because creator of that language probably had not need this type of language construction. Because it is better to let things be simpler.

Jii
  • 7
  • 1
  • 4