Lisp has syntax. More than any other programming language.
What you think Lisp syntax is, are really simple function calls like
(+ 1 2)
which are based on the function + various args pattern.
But something like Common Lisp has a few dozen syntactic built-in forms. For example the syntax for LET is in an EBNF (extended backus naur form) form:
let ({var | (var [init-form])}*) declaration* form*
Then Lisp has macros. Zillions. Each of them implements syntax.
Lisp has a two-stage syntax:
1. stage are s-expressions, a data format: symbols, numbers, lists, strings, ...
2. stage are Lisp forms. They are written as s-expressions. But they have to follow a defined syntax. not every s-expression is a valid Lisp form.
(let ((a 1) (b 2))
(declare (integer a b))
(+ a b))
Above is a valid LET form.
(let ((a 1) (b 2))
(+ a b)
(declare (integer a b)))
Above is not a valid LET form, because the syntax requires that the optional declaration is directly after the binding form.
Without parentheses it might look like:
let (a 1) (b 2)
declare integer a b
a + b
You would think that it has a syntactic structure. Just because Lisp uses s-expressions as a base mechanism, does not mean Lisp has no syntactic structure - but it is on top of s-expressions.
Since Lisp has user-programmable syntax, there is basically an unlimited amount of all kinds of syntactical constructs.
Another helpful comparison is Lisp syntax versus Forth syntax. If you actually want a simple, terse, unstructured language, Forth is the way to do it: Words will consume and return any number of inputs or outputs to the stack, and you get entire classes of error when it's unbalanced that would surface as syntax errors anywhere else.
Just adding s-expressions is actually a huge jump up in syntactic complexity and structure, since now you can define a whole hierarchy statically, "on the page", instead of having to use a series of stack operations to manipulate memory from afar. And then as you lucidly put it, going from s-expressions to a practical Lisp dialect adds another level of context on top of that.
(And yeah, it's possible to bolt structure onto a Forth dialect, too, but the "Chuck Moore way" is that you do that custom every time you need it, instead of trying to generalize. Generalizing a concatenative structure leads to something like Factor.)
I really should adopt this view in my future posts.
I think the difference is most people, myself included, are looking at basically the syntax as where the capital letter and the sentence ending punctuation go. Which is really the only mostly constant thing in most sentences. You raise a vital point that that is a small part of the syntactic makeup of a sentence.
Which is funny, because so many people are convinced you get no static help in lisp. Which is demonstrably wrong.
Lisp has syntax. More than any other programming language.
What you think Lisp syntax is, are really simple function calls like
which are based on the function + various args pattern.But something like Common Lisp has a few dozen syntactic built-in forms. For example the syntax for LET is in an EBNF (extended backus naur form) form:
Then Lisp has macros. Zillions. Each of them implements syntax.Lisp has a two-stage syntax:
1. stage are s-expressions, a data format: symbols, numbers, lists, strings, ...
2. stage are Lisp forms. They are written as s-expressions. But they have to follow a defined syntax. not every s-expression is a valid Lisp form.
Above is a valid LET form. Above is not a valid LET form, because the syntax requires that the optional declaration is directly after the binding form.Without parentheses it might look like:
You would think that it has a syntactic structure. Just because Lisp uses s-expressions as a base mechanism, does not mean Lisp has no syntactic structure - but it is on top of s-expressions.Since Lisp has user-programmable syntax, there is basically an unlimited amount of all kinds of syntactical constructs.