Daniel Jomphe's Library tagged lisp →  View Popular

I’m of the belief that compiler checks don’t eliminate or even reduce programmer stupidity. They just make it go deeper by creating complexity. Have I written my fair share of stupid python code? Sure. But it’s rare that I ever find myself saying “WTF is this code doing?”

But you obviously view things differently and that’s a good thing.

Lisp's irregular syntax are practically confusing.
For example, the difference between
“(list 1 2 3)”,
“'(1 2 3)”,
“(quote (1 2 3))”
is a frequently asked question.
The use of “` , ,@” etc are esoteric. If all these semantics use the regular syntactical form “(f args)”, then much confusion will be reduced and people will understand and use these features better.
For example, The
“'(1 2 3)”
might be changed to “(' 1 2 3)”, and

(setq myListXY `(,@ myListX ,@ myListY))

could have been:

(setq myListXY (eval-parts (splice myListX) (splice myListY)))

or with sugar syntax for typing convenience:

(setq myListXY (` (,@ myListX) (,@ myListY)))”

A regular nested syntax has a one-to-one correspondence to the language's abstract syntax tree, and to a large extent the syntax has some correspondence to the language's semantics.
The irregularities in syntax break this correspondence.

For example, programers can pretty much tell what piece of source code “(f x1 x2 x3 ...)” do by just reading the name that appears as first element in the paren. As a contrast, in syntax soup languages such as Java, Perl, the programmer must be familiar with each of its tens of syntactical forms. (e.g. “if (...) {...}”, “for (...; ...; ...) {...}”, “(some? this: that)”, “x++”, “myList = [1, 2, 3]” etc.)
As a example, if lisp's “'(1 2 3)” is actually “(quote 1 2 3)” or shortcut form “(' 1 2 3)”, then it is much easier to understand.

In lisp communities, it is widely recognized that lisp's regular syntax has the property that “code is data; data is code”. However, what does that mean exactly is usually not clearly understood in the lisp community. Here is its defining characteristics:

A regular nested syntax, makes it possible to do source code transformations trivially with a lexical scan.

The benefits of a regular syntax has become widely recognized since mid 2000s, by the XML language.
The XML language, due to its strict syntactical regularity, has developed into many transformation technologies such XSLT, XQuery, STX etc. See XML transformation languages↗.

Because lisp's syntax has lots of nested parenthesis, the source code formatting is much more labor intensive than syntax soup languages such as Perl, even when using a dedicated lisp editor such as emacs that contain large number editing commands on nested syntax.

The lisp community, established a particular way of formatting lisp code as exhibited in emacs's lisp modes and written guides of conventions. The recognition of such convention further erode any possibility and awareness of automatic, uniform, universal, formatting. (e.g. the uniform and universal part of advantage is exhibited by Python)

As a example, the Mathematica language features a pure nested syntax similar to lisp but without irregularities. So, in that language, since version 3 released in 1996, the source code in its editor are automatically formatted on the fly as programer types, much in the same way paragraphs are automatically wrapped in a word processor since early 1990s

One of the power of such pure nested syntax is that you could build up layers on top of it, so that the source code can function as markup of conventional mathematical notations (i.e. MathML) and or as a word-processing-like file that can contain structures, images (e.g. Microsoft Office Open XML↗), yet lose practical nothing.

This is done in Mathematica in 1996 with release of Mathematica version 3. (e.g. think of XML, its uniform nested syntax, its diverse use as a markup lang, then, some people are adding computational semantics to it now (i.e. a computer language with syntax of xml. e.g.
O:XML↗). You can think of Mathematica going the other way, by starting with a computer lang with a regular nested syntax, then add new but inert keywords to it with markup semantics. The compiler will just treat these inert keywords like comment syntax when doing computation. When the source code is read by a editor, the editor takes the markup keywords for structural or stylistic representation, with title, chapter heading, tables, images, animations, hyperlinks, typeset math expression (e.g. think of MathML↗) etc. The non-marked-up keywords are shown as one-dimensional textual source code just like source code is normally shown is most languages.)

Ultimately, you have to ask why lisper advocate nested syntax in the first place.

If lispers love the nested syntax, then, the argument that there should not be irregularities, has merit. If lispers think occasional irregularities of non parenthesized syntax is good, then there's the question of how many, or what form.

Lisp at core is based on functional programing on lists. This is comparatively a powerful paradigm. However, for historical reasons, lisp's list is based on the hardware concept of “cons” cell. From a mathematical point of view, what this means is that lisp's lists is limited to a max of 2 elements. If you want a longer list, you must nest it and interpret it in a special way. (i.e. effectively creating a mini-protocol of nesting lists, known as proper lists.) The cons fundamentally crippled the development of list processing.

Lisp being historically based the cons for like 2 or 3 decades. The
cons (and cdr, car, caadar etc) are fundamentally rooted in the lisp
langs, is thus not something that can be easily mended. This is
unfortunate. However, this situation could be improved.

(by, for
example, exposing only higher-level list manipulation functions in all
newer literature, or even mark cons related functions as obsolete)

One of the myth that is quickly injected into budding lispers, is that cons are powerful. It is powerful in the sense any assembly lang is powerful. Lisp's cons is perhaps the greatest fuck up in the history of computer languages.

If you don't like cons, lisp has arrays and hashmaps, too.

I like the cons concept. Even in functional languages like Haskell it is popular, e.g. when matching in the form of (x:xs), which is the same like car/cdr in Lisp.

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.