tearflake (u/tearflake)

tearflake commented on A different take on S-expressions gist.github.com/tearflake... · Posted by u/tearflake

luizfelberti · 2 months ago

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.

tearflake · 2 months ago

Actually it's quite simple. We parse from left to right. When we hit EOL, we return to the beginning of line and increase Y by one.

Blocks are parsed in the following way: when we get the beginning count of block opening characters, we move Y by one, loop right while whitespace, until we encounter ending count of block characters.

In transposed block, we just switch X and Y, it is easily done with pointers, and use the same code.

tearflake commented on A different take on S-expressions gist.github.com/tearflake... · Posted by u/tearflake

unstruktured · 2 months ago

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

tearflake · 2 months ago

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

tearflake commented on A different take on S-expressions gist.github.com/tearflake... · Posted by u/tearflake

uncircle · 2 months ago

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

tearflake · 2 months ago

Solves a mess with closing parens. But I'm not sure if it is worth of hassle. Anyway, it exists.

tearflake commented on A different take on S-expressions gist.github.com/tearflake... · Posted by u/tearflake

exeldapp · 2 months ago

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.

tearflake · 2 months ago

That looks clean, can't argue that.

tearflake commented on A different take on S-expressions gist.github.com/tearflake... · Posted by u/tearflake

davesque · 2 months ago

This is bonkers and I love it.

tearflake · 2 months ago

Ikr? People should loosen a bit, why should everything be so serious?

tearflake commented on A different take on S-expressions gist.github.com/tearflake... · Posted by u/tearflake

unstruktured · 2 months ago

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

tearflake · 2 months ago

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

tearflake commented on A different take on S-expressions gist.github.com/tearflake... · Posted by u/tearflake

stray · 2 months ago

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

tearflake · 2 months ago

Changed the "somewhat" to "very" in the document, thank you.

tearflake commented on A different take on S-expressions gist.github.com/tearflake... · Posted by u/tearflake

drob518 · 2 months ago

As a Lisp programmer, just no.

tearflake · 2 months ago

Thank you for the criticism. Lots of lispers share your opinion.

tearflake commented on A different take on S-expressions gist.github.com/tearflake... · Posted by u/tearflake

pkilgore · 2 months ago

Is this.... is this a joke?

tearflake · 2 months ago

I don't intend to be funny. Just a bit childish, but in a good way :)

tearflake commented on A different take on S-expressions gist.github.com/tearflake... · Posted by u/tearflake

phoe-krk · 2 months ago

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.

tearflake · 2 months ago

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.