[practal]

I think simpler is better when it comes to structured editing. Recursive teXt has the advantage that it proposes a simple block structure built into the text itself [1]. Of course, you will need to design your language to take advantage of this block structure.

[1] http://recursivetext.com

[computably]

Since Lisp has been around since 1960... Congratulations, you're only about 64 years late.

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

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

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