News for hackers. Stuff that matters.
Re:A different take on S-expressions by phoe-krk on Wednesday June 18, 2025 @12:45PM (#44311409)
Lisp programmer here.

Traditional S-expressions, by their definition, ignore most of whitespace; additionally, reading sexprs is always a linear operation without the need to backtrack by more than one character.

The suggestion from this post violates both assumptions by introducing a 2D structure to code. To quote this post's examples, it requires the multiline string in

    (fst-atom """   trd-atom)
              00001
              00002
              00003
                """
to be fully read before TRD-ATOM. It also forces the reading function to jump up and down vertically in order to read the structure in

    * (                               )  
    *   e (           ) (           )    
    *   q   m (     )     p (     )     *
            u   a a       o   a 2       *
            l             w             *
The author also states that

    (eq (mul (a a)) (pow (a 2)))
is less readable than

    * (                                                  )  
    *   *eq* (                   ) (                   )    
    *          *mul* (         )     *pow* (         )     *
                       *a* *a*               *a* *2*       *
                                                           *
Then there's the ending passage:

> we hope that the introduced complexity is justified by the data readability expressed this way.

I cannot force myself to read this post as anything but a very poor Befungesque joke.

Re:A different take on S-expressions by velcrovan on Wednesday June 18, 2025 @02:18PM (#44312113)
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
Re:A different take on S-expressions by perrygeo on Wednesday June 18, 2025 @09:58PM (#44314788)
That's amazing and terrible at the same time. I love it.
Re:A different take on S-expressions by phoe-krk on Thursday June 19, 2025 @02:17AM (#44315945)
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.
Re:A different take on S-expressions by tgv on Wednesday June 18, 2025 @01:07PM (#44311589)
A normal tree would be easier to read

            eq
       mul      pow
     a    a    a   2
Re:A different take on S-expressions by derriz on Wednesday June 18, 2025 @05:00PM (#44313236)
Turned 90, maybe?

  eq:
    mul:
      a
      a 
    pow:
      a
      2
Re:A different take on S-expressions by hyperhello on Wednesday June 18, 2025 @05:10PM (#44313301)
x*x == pow(x,2)
Re:A different take on S-expressions by derriz on Wednesday June 18, 2025 @05:13PM (#44313325)
We have a winner!

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

Re:A different take on S-expressions by xigoi on Wednesday June 18, 2025 @06:47PM (#44313942)
x · x = x²
[dead]
Re:A different take on S-expressions by amno on Friday June 20, 2025 @04:23AM (#44325680)
(= * x x ^ x 2)
Re:A different take on S-expressions by unrealhoang on Wednesday June 18, 2025 @09:30PM (#44314666)
no yaml programming please :(
Re:A different take on S-expressions by uncircle on Thursday June 19, 2025 @02:27AM (#44316009)
From the YAML inventor himself: https://yamlscript.org/

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

Re:A different take on S-expressions by tgv on Sunday June 22, 2025 @05:52AM (#44345512)
That's the classical LISP way of doing it:

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

    (eq
        (mul
             a
             a
        )
        (pow
             a
             2
        )
    )
Re:A different take on S-expressions by f1shy on Wednesday June 18, 2025 @02:57PM (#44312399)
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.

Re:A different take on S-expressions by unstruktured on Wednesday June 18, 2025 @01:40PM (#44311838)
Thanks for restoring my sanity. Was quite confused of the value added by the author.
Re:A different take on S-expressions by tearflake on Wednesday June 18, 2025 @05:25PM (#44313403)
Sorry for the confusion. I must be a very disturbed person because I kind of like what is explained there.
Re:A different take on S-expressions by tearflake on Thursday June 19, 2025 @03:31AM (#44316356)
Here, I brought down the enthusiasm a bit in the closing word. I hope it creates less confusion now.
Re:A different take on S-expressions by tearflake on Wednesday June 18, 2025 @05:14PM (#44313329)
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.
Re:A different take on S-expressions by exeldapp on Wednesday June 18, 2025 @06:18PM (#44313749)
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.
Re:A different take on S-expressions by tearflake on Wednesday June 18, 2025 @07:47PM (#44314221)
That looks clean, can't argue that.