It gets worse/better. Since Racket allows you to hook your own reader in front of (or in place of) the default reader, you can have things like 2D syntax:

    #lang 2d racket
    (require 2d/match)
     
    (define (subtype? a b)
      #2dmatch
      ╔══════════╦══════════╦═══════╦══════════╗
      ║   a  b   ║ 'Integer ║ 'Real ║ 'Complex ║
      ╠══════════╬══════════╩═══════╩══════════╣
      ║ 'Integer ║             #t              ║
      ╠══════════╬══════════╗                  ║
      ║ 'Real    ║          ║                  ║
      ╠══════════╣          ╚═══════╗          ║
      ║ 'Complex ║        #f        ║          ║
      ╚══════════╩══════════════════╩══════════╝)

https://docs.racket-lang.org/2d/index.html

Truth be told, you can intercept the reader in Common Lisp, too, and here it actually makes some sense since the 2D value is immediately visually grokkable as an ASCII-art table. The proposed 2D sexpr notation does not have this.

That's amazing and terrible at the same time. I love it.

A normal tree would be easier to read

            eq
       mul      pow
     a    a    a   2

Turned 90, maybe?

  eq:
    mul:
      a
      a 
    pow:
      a
      2

That's the classical LISP way of doing it:

    (eq (mul a
             a)
        (pow a
             2))

or

    (eq
        (mul
             a
             a
        )
        (pow
             a
             2
        )
    )

x*x == pow(x,2)

We have a winner!

Actually, I'd suggest a slight improvement: x*x = x^2

x · x = x²

(== (* x x) (pow x 2))

(= * x x ^ x 2)

no yaml programming please :(

From the YAML inventor himself: https://yamlscript.org/

The length people go to avoid Lisp, only to reinvent it, badly.

Yes that part must be a joke!

I’ve seen dozens of attempts to make S-Exp “better” even the original M-Exp. I also did some experiments myself. But at the end, I come back to goo’ol s-exp. Seems to be a maximum (or minimum) found just perchance.

Here is another example, an axiom from propositional logic:

    (impl (impl p (impl q r)) (impl (impl p q) (impl p r)))

which, vertically indented in a transposed block, looks like this:

    * (                                               )
    *   i (               ) (                       )
    *   m   i p (       )     i (       ) (       )
        p   m     i q r       m   i p q     i p r
        l   p     m           p   m         m           *
            l     p           l   p         p           *
                  l               l         l           *

which, using transposed lines within the transposed block, finally looks like this:

    * (                                                                                           )
    *   *impl* (                               ) (                                              )   *
    *            *impl* *p* (                )     *impl* (                ) (                )     *
                              *impl* *q* *r*                *impl* *p* *q*     *impl* *p* *r*       *

This time I won't make any judgements. Could be good, could be bad, you decide.

Not sure if that example helps. You can make any programming language hard to read without some basic formatting. The way I would write the sexpr would be:

  (impl
    (impl 
       p 
       (impl q r))
    (impl
       (impl p q)
       (impl p r)))

It's clear when each section begins and ends and doesn't require complex parsing rules.

That looks clean, can't argue that.

Thanks for restoring my sanity. Was quite confused of the value added by the author.

Sorry for the confusion. I must be a very disturbed person because I kind of like what is explained there.

Here, I brought down the enthusiasm a bit in the closing word. I hope it creates less confusion now.