Comment by lispm

> I'm not sure how you think S-expressions are any more optimized for expressions than, for example, infix notation.

They aren't. But they are optimized to represent expressions as simple data: nested lists. One could write infix expressions as a data structure:

(a + b * (c + d) * 3)

READ converts it into a list. For that one could write a simple evaluator, a simplifier, or other tools based on simple list processing.

> Really I can only identify one feature which falls out of S-expressions, which can't be obtained with other syntaxes: macros.

Macros are one application of processing of s-expressions. The more general feature is representing any type of code as nested lists -> symbolic expressions. They are a compromise between a human-readable, textual & internal data format and machine processable code. Lisp code is just one application of that. It could be Prolog code, expressions of a theorem prover, or anything else which sports a custom processing engine and a lean way to input/process/output code as data.

Actually macros can be obtained with other syntaxes. The Lisp way to represent code externally and internally as s-expressions is just one way. It's relatively simple and primitive. A simple interpreter for Lisp code can be written in a page of Lisp -> processing engines can also be very simple. The input and output of code then already provided by the reader and printer of s-expressions.

Thus one can use s-expressions to design notations that are BOTH trivially a data structure with a textual representation AND processable with a simple predefined 'list processor' (aka Lisp) or any other custom "list processor".

Looking at the textual representation in isolation is missing the bigger picture: it's the simple textual representation of lists AND a simple "list processor".