[llm_trw]

I wrote a racket function that would need 35 levels of indentation ten minutes ago. White space isn't coming for lisps until we figure out 12 dimensional displays.

[shakna]

Wisp [0] is the big one talked about in Scheme land, and it wouldn't need 35 levels of indentation. Like the rest of Lisp-world, there's flexibility where you need it.

For example, this shows a bit of the mix available:

      for-each
       λ : task
           if : and (equal? task "help") (not (null? (delete "help" tasks)))
                map
                  λ : x
                      help #f #f x
                  delete "help" tasks
                run-task task
       . tasks

[0] https://srfi.schemers.org/srfi-119/srfi-119.html

[cjfd]

Is a function that would need 35 levels of indentation a good idea? I have seen C code with about 12 levels of indentation and that was not too great.

[llm_trw]

What other languages use syntax for lisps use function applications for.

Viz. the array reference a[0] in algols is a function application in lisps (vector-ref a 0).

The same is true for everything else. Semantic white space in such a language is a terrible idea as everyone eventually finds out.

[benatkin]

An everyday example is the difference between JSON.stringify(data, null, 2) and a pretty printer like ipython or Deno.inspect. Having only one node per line reduces the amount of data that can be displayed. It's the same with code.

[practal]

Recursive teXt (RX) would be a great fit for Lisp, although I am more interested in replacing Lisp entirely with a simpler language rooted in abstraction logic.

Note that RX is not like normal semantic white space, but simpler. It is hard coded into the text without taking its content into consideration. RX is basically nested records of text, making it very robust, but encoded as plain text instead of JSON or something like that.

[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]

Assuming this number of indentation is really necessary (which I doubt; maybe a few auxiliary definitions are in order?), obviously only the first few levels would be represented as their own Recursive teXt blocks.

[llm_trw]

>obviously only the first few levels would be represented as their own Recursive teXt blocks.

This is not at all obvious.

[practal]

It is obvious to me, nobody would want to represent 35 levels of nesting by indentation. So I would represent the first few (2-4) levels in RX, and the rest by other means, such as brackets. Your language should be designed such that the cutoff is up to you, the writer of the code, and really just a matter of syntax, not semantics.

Obviously, I (usually) would not want to write things like

    + 
        * 
            a 
            b
        * 
            c 
            d

but rather

    +
        a * b
        c * d

or, even better of course,

    (a * b) + (c * d)

I think of blocks more as representing high-level structure, while brackets are there for low-level and fine-grained structure. As the border between these can be fluid, where you choose the cutoff will depend on the situation and also be fluid.

[llm_trw]

>Your language should be designed such that the cutoff is up to you, the writer of the code, and really just a matter of syntax, not semantics.

I have more important things to think about in my code than when I switch between two dialects of the language.

Especially since I get no extra expressive power by doing so.

>Obviously, I (usually) would not want to write things like

Or just use (+ (* a b) (* c d)) which is simpler that any of the example above. Then I can chose between any of:

    ( +
      (* a b)
      (* c d))

    ( +
      ( *
       a
       b
      )
      ( *
        c
        d
      ) 
    )
    

Or whatever else you want to do.

>As the border between these can be fluid, where you choose the cutoff will depend on the situation and also be fluid.

It's only fluid because you've had XX years of infix notation caused brain damage to make you think that.

[practal]

> I have more important things to think about in my code than when I switch between two dialects of the language.

Granted. The example I gave was just to demonstrate that switching between the styles is not a problem and can be fluid, if you need it to be.

> It's only fluid because you've had XX years of infix notation caused brain damage to make you think that.

No, infix is just easier to read and understand, it matches up better with the hardware in our brains for language. If that is different for you, well ... you mentioned brain damage first.

[llm_trw]

The average programmer has 12 years of education before they have a chance to see superior notations like prefix and postfix.

Of course you'll think that the two are weird when you've never had a chance to use them before you're an adult.

Much like how adults who are native english speakers see nothing wrong with the spelling, but children and everyone else does.

[Dylan16807]

> Or just use (+ (* a b) (* c d)) which is simpler that any of the example above. Then I can chose between any of:

That's the exact same flexibility but in a different order. It's not simpler.