[llm_trw]

No it won't be. S-expressions are the simplest way to linearize a tree.

Everyone thinks there's something better and the very motivated write an interpreter for their ideal language in lisp.

The ideas inevitably have so much jank when used in anger that you always come back to sexp.

Now if you discover a way to linearize dags or arbitrary graphs without having to keep a table of symbols I'd love to hear it.

[practal]

> S-expressions are the simplest way to linearize a tree.

S-expressions are one way to linearize a tree.

Now, "simple" can mean different things depending on what you are trying to achieve. RX is simpler than s-expressions if you prefer indentation over brackets, and like the robustness that it brings. Abstraction algebra terms are simpler than s-expressions if you want to actually reason about and with them.

[llm_trw]

In your own examples you're using both brackets and white space to delineate structure. This is complex because you need two parsers to even start working on the input stream and the full parser must know how to switch between them.

In short: I get all the pain of semantic white space with all the pain of lisp s-exp's with the benefits of neither.

[practal]

In my examples I use RX for the outer structure, which is unproblematic, as RX itself is not complex at all, and parsing it is easy, as easy as parsing brackets.

What kind of content you put into the blocks, depends on you. How you parse one block is independent from how you parse another block, which means embedding DSLs and so on is painless. You could view the content of a block as RX, but you can also just see it as plain text that you can parse however you choose.

This also means if you make a syntax error in one block, that does not affect any other sibling block.

The benefits of RX, especially at the outer level, is that all those ugly brackets go away, and all you are left with is clear and pleasing structure. This is especially nice for beginners, but I am programming for over 30 years now, and I like it also much better.

If you don't see that as a benefit, good for you!

[kazinator]

If you don't allow the indentation based parsing to be nested within a bracket-based expression, it doesn't look too bad. At the top level you have the indentation-based parser. When that sees an open bracket, it recurses to the regular parser which doesn't care about indentation.

[llm_trw]

This works until you start using macros.

[kazinator]

I'm reasonably sure you could conceal this surface syntax so that macros don't know it exists and work fine. You can call a macro by writing the invocation syntax using the indented format, or by the bracketed format, or a mixture.

It's been done before; see Scheme SRFI-110, a.k.a. Sweet Expressions or t-expressions:

https://srfi.schemers.org/srfi-110/srfi-110.html

[practal]

Yes, for a general language (such as abstraction algebra) you would want to allow mixing normal term language and blocks. In RX, that is easy to do: Just reuse the blocks that RX already gives you, while the lines of a block are there for the term language.