> while what you really need

need for what?

> is a good way to manipulate the ast (for good/easy macro support).

S-expressions were not initially used in Lisp because of macros. Actually the early Lisp had no macros, but s-expressions. They were used as a syntax and representation for lists and tree-like data.

s-expressions were first used as a data representation and people had to use it, because programs were represented as s-expressions. The programs were written as m-expressions in some algebraic notation, but had to be translated to s-expressions to be executed by Lisp. The expectation was that s-expressions were only an implementation detail and programmers were then using some other syntax for their programs. There were some larger efforts to design a successor to Lisp 1.5 (called Lisp 2) with such a syntax and have that as the default/main Lisp dialect. Eventually this project was cancelled.

http://www.softwarepreservation.org/projects/LISP/lisp2_fami...

The advantages of s-expressions in the context of Lisp were/are:

* not dependent on line-based data entry and not sensitive to whitespace

* one could easily feed code as s-expressions to a interpreter, this could be a Lisp interpreter, or an interpreter for some other language using s-expressions.

* the parsing/scanning/printing/formatting of s-expressions is reusable in different contexts. this can be done with or without knowing the contents of s-expressions. One can easily format s-expressions based on general rules, but one can also write special purpose code formatter for Lisp. Lisp has this built-in with the pretty-printer.

* generally writing code transformations (not just Lisp macros) is a bit easier with richer data structures than strings. For example write a bunch of rules using s-expression and transform/interpret them. Thus different interpreters/compilers can be easily written, not just a Lisp interpreter/compiler.

* interactive manipulation of s-expressions and s-expression-based code is relatively easy. This helps a lot with REPL-style programming. Marking (sub-)expressions, transposing them, replacing/moving them, then gets relatively easy. You'll get a poor-man's syntax directed editing very easy. If you want in an IDE make a Java-expression available broken up into its subexpressions, one has to use a much more complicated parser, which then has very detailed knowledge about the language - which is both and good. With s-expressions you still get some structure editing, while on that level there is very little commitment about the syntax of the actual contents (is it a Lisp program? Is it a bunch of rules for a firewall? is it a list of diagnosis rules?).

Syntax-directed editing is available in many tools, but rarely is it as interactive and basic as in Lisp with s-expression syntax, which is also very robust against accidentally reformatting (omitted newlines, added whitespace, ...). Enter an s-expression and its always easy to reconstruct the visual structure.

Since (sub-)expressions are delimited left and right with characters ( and ), it's always clear where it starts and ends when displayed or read. With a syntax with less visual structure or one which needs to be reconstructed with a parser, this is much more difficult and less intuitive to use.