[practal]

No doubt, brackets of course also convey structure. But I think indentation is better for visualising block structure. Inside these blocks, you can still use brackets, and errors like missing opening or closing brackets will not spill over into other blocks.

And yeah, I am definitely coming for Lisp.

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

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

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

[computably]

> But I think indentation is better for visualising block structure.

Which is irrelevant, because you can visualize code however you want via editor extensions.

> And yeah, I am definitely coming for Lisp.

An endeavor which is simultaneously hopeless and pointless.

[practal]

> Which is irrelevant, because you can visualize code however you want via editor extensions.

Semantically, of course this does not matter. A block is a block, no matter if delineated by indentation or brackets. But RX looks better as plain text, and there is much less of a disconnect between RX as plain text, and RX as presented in a special editor (extension) for RX, than there would be for Lisp.

> An endeavor which is simultaneously hopeless and pointless.

Challenge accepted.