[Decabytes]

> Why have operators at all?

I mean as an avid Lisp fan, I feel like Lisp basically answers the question of how much syntax you need in a langauge. I must admit though, not having to deal with operators precedence is really nice

  (mod (+ x (* 2 step)) width)

[kazinator]

Also, having them if you want is nice:

  1> let ((x 3) (step 2) (width 5)) ((2 * step + x) mod width)
  2

This is TXR Lisp with auto-infix and auto-compound enabled for the REPL:

  2> *listener-auto-infix-p*
  t
  3> *listener-auto-compound-p*
  t

So we can omit the outermost parentheses, and infix syntax is automatically recognized, freely intermixed with regular Lisp, as if the (ifx ...) macro were wrapped around the input.

I've come up with a very good way of handling infix in Lisp, and documented it in a decent amount of detail as well, not just as a manual for the user but anyone wanting to implement something similar.

https://www.nongnu.org/txr/txr-manpage.html#N-BEB6083E

[adrian_b]

Regarding operators, there are 3 distinct problems.

One is to allow the use of simple mathematical symbols as names for functions, instead of allowing only alphanumeric identifiers.

Most programming languages allow only a small fixed set of symbols to be used as "operators", i.e. as function names.

The better solution is to allow any Unicode character from certain categories, e.g. "Sm" and "Po" ("Symbol, math" and "Punctuation, other"), which does not have an already assigned role in the language syntax, to be used as a function name.

Most LISP variants allow the use of various kinds of character symbols as function names.

The second problem is overloading. Overloading must be treated uniformly for any kind of functions, regardless if their names are identifiers or operator symbols, i.e. not like in Java, where forbidding operator overloading was a mistake (that was an overreaction to C++, which allows the overloading of a few "operators" that are not normal functions and whose overloading should not have been allowed, e.g. the comma operator).

The overloading of operators, especially for user-defined data types is something absolutely essential for scientific and technical computing.

The majority of programmers have not been exposed to programs that contain a great amount of computations, so they are accustomed only with simple expressions that contain a few variables.

In scientific and technical computing it is very frequent to have very big expressions, which may contain a large number of operations and variables, where the variables may have various types, like complex numbers, vectors, matrices, complex vectors, complex matrices, or there may be a type system with distinct types for various physical quantities, like voltages, electric currents, capacitances and so on.

Anyone who had to write frequently such big expressions will definitely prefer, both for writing and for reading, to use overloaded operator symbols instead of long function names, which would fill most of the visual space with superfluous characters, obscuring the structure of the big expression.

The third problem is the syntax of function invocation. Most programming languages allow functions whose names are identifiers to use only prefix invocation but for some symbolic operators they allow infix invocation.

Here I also prefer the languages that do not differentiate between functions with alphanumeric names and functions with symbolic names (i.e. operators). There are languages where for any function it may be specified that it must be invoked as an infix operator, if this is desired.

Which is the best between the 3 classic solutions for expression syntax, traditional expressions with infix operators and multi-level precedence rules (like in FORTRAN and ALGOL), expressions with infix operators and a unique precedence rule for all operators (like in APL) and expressions without infix operators (like in LISP), is debatable.

Each of the 3 solutions has advantages and disadvantages, so the choice between them is a matter of personal preferences.