Daniel Jomphe's Library tagged learning →  View Popular

The math notation we encounter in school, such as “1+2”, is called
Infix Algebraic Notation. Algebraic notations have the concept of
operators, meaning, symbols placed around arguments. In algebraic
infix notation, different symbols have different stickiness levels
defined for them. e.g. “3+2*5>7” means “(3+(2*5))>7”, not
“((3+2)*5)>7”, because the operator “*” has a higher
stickness than the operator “+”, and “+”
has a higher stickness than the “>” operator. The
stickiness of operator symbols is normally called “Operator
Precedence”. It is done by giving a order specification for the
symbols, or equivalently, give each symbol a integer index, so that
for example if we have “a⊗b⊙c”, we can unambiguously understand it to
mean one of “(a⊗b)⊙c” or “a⊗(b⊙c)”.

In a algebraic postfix notation known as Polish Notation, there needs not to have the concept of Operator Precedence. For example, the infix notation “(3+(2*5))>7” is written as “3 2 5 * + 7 >”, where the operation simply evaluates from left to right. Similarly, for a prefix notation syntax, the evaluation goes from right to left, as in “> 7 + * 5 2 3”.

While functional notations, do not employ the concept of Operators,
because there is no operators. Everything is a syntactically a
“function”, written as “f(a,b,c...)”. For example, the same expression
above is written as “>( +(3, *(2,5)), 7)” or “greaterThan( plus(3,
times(2,5)), 7)”.

For lisps in particular, their fully functional notation is
historically termed sexp (short for S-Expression, where S stands for
Symbolic). It is sometimes known as Fully Parenthesized Notation. For
example, in lisp the above example is written as: “(> (+ 3 (* 2 5)) 7)”.

Placing the head in front of the
matching bracket makes the notation more familiar, because it is
the same how math are written traditionally.

However, there is a disadvantage in moving the head of a expression
from inside the matching bracket to outside. Namely: The nesting of
the matching delimiters, no longer corresponds to the logics of the
syntax, when the head is itself a compound expression.

In Mathematica, there are other syntax variations beside the
above mentioned systematic constructs. For example, Plus[a,b,c] can be
written as “a+b+c”, “Plus[a+b,c]”, “Plus[Plus[a,b],c]”, or
“(a+b)~Plus~c”. “List[a,b,c]” can be written as “{a,b,c}”, and
“Map[f,List[a,b,c]]” can be written as “f /@ {a,b,c}”.

The gist being that certain functions are given a special
syntactical construct to emulate the irregular and inefficient but
nevertheless well-understood conventional notations. Also, it reduces
the use of deep nesting that is difficult to type and manage. For
example, the “Plus” function is given a operator “+”, so that
“Plus[3,4]” can be written with the more familiar “3+4”. The “List”
function is given a syntax construct of “{}”, so that, “List[3,4]” can
be more easily written as “{3,4}”. The boolean “And” function is given
the operator “&&”, so that “And[a,b]” can be written with the
more familiar and convenient “a && b”. Combining all these
types of syntax variations, it can make the source code easier to read than a
purely nested structure. For example, common math expressions such as
“3+2*5>7” don't have to be written as
“Greater[Plus[3,Times[2,5]],7]” or the lispy “(> (+ 3 (* 2 5))
7)”.

Note: it can also make the source code harder to read if the notations are mixed up unreasonably or intentionally as in obfuscated code.

When we say that C is a infix notation language, the term “infix notation” is used loosely for convenience of description. C and other language's syntaxes derived from it (e.g. C++, Java, Perl, Javascript...) are not based on a notation system, but takes the approach of a ad hoc syntax soup. Things like “i++”, “++i”, “for(;;){}”, “while(){}”, 0x123, “expr1 ? expr2 : expr3”, “sprint(...%s...,...)”, ... are syntax whimsies.

As a side note, the Perl mongers are proud of their slogan of
“There Are More Than One Way To Do It” in their gazillion ad hoc
syntax sugars but unaware that in functional languages (such as
Mathematica, Haskell) that there are consistent and generalized
constructs that can generate far more syntax variations than the ad
hoc inflexible Perl both in theory AND in practice. And, more
importantly, Perlers clamor about Perl's “expressiveness” more or less
on the syntax level but don't realize that semantic expressibility is
far more important.

The third issue, about how nested syntax seriously discourages frequent or advanced use of inline function sequencing on the fly, is the most important and I'll give further explanation below.

One practical way to see how this is so, is by considering unix's
shell syntax. You all know, how convenient and powerful is the unix's
pipes. Here are some practical example: “ls -al | grep xyz”, or “cat a
b c | grep xyz | sort | uniq”.

Now suppose, we get rid of the unix's pipe notation, instead,
replace it with a pure functional notation: e.g. (uniq (sort (grep xyz
(cat a b c)))), or enrich it with a composition function and a pure
function construct, so this example can be written as:
((composition uniq sort (lambda (x) (grep xyz x))) (cat a b c)).

You see, how this change, although syntactically equivalent to the
pipe “|” (or semantically equivalent in the example using function
compositions), but due to the cumbersome nesting of parenthesis, will force a
change in the nature of the language by the code programer
produces. Namely, the frequency of inline sequencing of functions on
the fly will probably be reduced, instead, there will be more code
that define functions with temp variables and apply it just once as
with traditional languages.

Lisp, by sticking with a almost uniform nested parenthesis notation,
it immediately reduces the pattern of sequencing functions, simply
because the syntax does not readily lend the programer to it as in the
unix's “x|h|g|f”. For programers who are aware of the coding pattern
of sequencing functions, now either need to think in terms of a
separate “composition” construct, and or subject to the much
problematic typing and deciphering of nested parenthesis. (in practice, it's mostly done by writing the inline functions as a auxiliary function definitions on their own, then another code block sequence them together.)

(Note: Lisp's sexp is actually not that pure. It has ad hoc syntax
equivalents such as the “quote” construct “ '(a b c) ”, and also “`”,
“#”, “,@” constructs, precisely for the purpose of reducing
parenthesis and increasing readability. Scheme's coming standard
the R6RS ↗, even proposes the
introduction of [] and {} and few other syntax sugars to break the
uniformity of nested parenthesis for legibility. Mathematica's
FullForm, is actually a version of unadulterated nested notation as
can be.