Data representations

If you forget for a moment that it's used as syntax in LISP, S-expressions are pretty neat.

Most programming languages use a mix of arrays, structures, vectors, lists, tuples, tables and/or objects to represent and handle data structures. Each of them are similar yet different aggregate structures. With S-expressions, however, there are only pairs or atomic data (doesn't contain a reference to any other value). What are lists? Ordered pairs. What are tuples? Lists. What are vectors? Lists. What are structs? Tuples with compile-time field-labels (implicit accessor procedures).

Now, some of you are complaining ``lists have linear complexity''! Well, ordered pairs only have to behave as linked pairs. They can be allocated in sequential memory locations for constant lookup. CDR-coding makes this automatic and the job of the GC (and CDR-coding is simple if cdrs aren't writable (like arrays or tuple suffixes)).

Good languages only need one tool for creating composite structures: ordered pairs.

Source: Anatomy of Lisp

>>6
M-expressions were supposed to be the way people programmed in Lisp. S-exprs were just meant to be an internal data structure, and the reason why hardly anyone uses Lisp. If Lisp had an ALGOL-like syntax like it was meant to, it would be much more popular than it is now. This is why people who create their own languages should never release any experimental features to the public until they're finished. Unfinished ideas and implementation details end up getting used in real programs and by the time the developer wants to change things it's too late. It's much easier to add than remove.