HN Reader

Feels like the complete opposite s-expressions which are the easiest possible thing to parse, this sounds like a complete nightmare to write a parser for.

It might even be easier to treat the input string as a 2D grid than as a sequence and have a parsing head that behaves like a 2x2 convolutional kernel...

This would make for either a great Advent of Code, or a nightmare interview question, I love it.

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.

These definitely are extensions that you could add to S-expressions, no one can disagree there.

Related but not the same at all, Racket has a 2D syntax (add on mode) that gives a different way to program tables where the output depends on two different inputs.

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

Is the empty list also an s-expression? If so, would it not be slightly more correct to define s-expressions as either an atom or a list of zero or more s-expressions?

Where is the grotesque code to parse these rectangles? :)

For very large values of "somewhat peculiar"...

I'll piggyback with my gruesome JSONification of S-expressions. I kinda liked having two kinds of braces [straight] and {curly} to differentiate arrays and objects, and I did have a event-loop-based "parallel" scheduler working to process a tree as soon as prerequisites were fulfilled. I might pick up the old project again someday, I just got hung up on how I wanted to handle error bubbling.

With a vertical script like japanese you could easily rotate the whole program 90 degrees to the right (as shown at the bottom of the landing page)

https://web.archive.org/web/20240904091932/https://lookalive...

  {
  "#!join": [
    [
      "A triangle with side of ",
      "#& side",
      " and base of ",
      "#& base",
      "has a hypotenuse of",
      {
        "#!sqrt": [
          [
            {
              "#!sum": [
                [
                  "#!multiply side side",
                  "#!multiply base base"
                ]
              ]
            }
          ]
        ]
      }
    ]
  ]
}

This is fine and interesting, but what I think is lacking in S-expression isn't funky vertical syntax, but a way to directly represent objects that are not lists. Otherwise one needs to invent some representation on top of S-expressions (and then a list isn't necessarily a list anymore; everything goes through an additional layer of encoding/decoding, losing the elegance of S-expressions), or use some extension syntax (usually involving '#'), which varies from language to language and might not even be interpreted by the reader (but logically expand to some list expression that needs to be interpreted again later, so you're not really any better off than with the first approach).

I kind of want something like, to borrow JSON-like syntax and gloss over namespacing issues:

  (foo .
    {type: listy-cons-cell
     head: bar
     tail: (baz quux)})

...which would be another way to say (foo bar baz quuz), but would make it possible to represent any data structure you like at the same level as atoms, strings, and lists.

This is bonkers and I love it.

dispense with the parentheses:

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

becomes

  eq
    mul
      a a
    pow
      a 2

As a Lisp programmer, just no.

I can only ask “…but why?” I don’t get what this complexity buys us.

Is this.... is this a joke?