So I'm very seriously considering making my language indentation based. You're saying you wouldn't like that?
Indentation based is a pain when copy-pasting between contexts with different indentation levels, as you have to fix it up manually, which is error-prone. In languages without it, you can just auto-format. (And even in an editor that doesn't support that, having a second indicator makes it less error-prone to fix manually)
No indeed I'm not a fan. I find it brittle and arbitrary for data values especially; that also makes automatic code generation and edition harder, for no good reason.
But that's not an important consideration either way.
For what it's worth, I love the semantics of many indentation based languages (F# for example) but really dislike editing them. Visually scanning is much easier with braces (imo) and it's much easier to navigate braced languages when using a vim-like editor
For somebody unable to empathize with the "braces are easier to scan" part, could yiu explain why?<p>I find it easy to see if things are on the same indentation. I find it much harder to visually scan for opening and closing braces unless syntax highliting makes them scream at me or they are accompanied by ...indentation.
I don't mind indentation based languages. I used to hate them, but they've grown on me after using python, Haskell, Idris, Agda, etc. And I ended up making my own language indentation based (it is similar to Idris).<p>That said, it is hard-mode:<p>- You'll have to figure out how to parse it.<p>- If you want editor support, it's a pain to get tree-sitter to handle it.<p>- You may not be able to pull off editor operations like "rename" without implementing a pretty printer (a rename might affect indentation).<p>I think it is helpful for crude error recovery. On parse error, my language will simply skip to the next column 0 token and parse another declaration.<p>I did not do this (hindsight), but I would recommend arranging the grammar so you only get indented blocks in cases where the previous line ends in a keyword that introduces it. I think python has a trailing `:` every time indentation is introduced, and
Elm does this too - in statements like `let` you need a newline after the `let` to get the multi-declaration version. (This addresses the rename issue.)
I think this falls under "[wanting] to know the user case the authors had in mind"
I love that people hate indentation based so I show them a poorly indented C style languages codebase to see how they feel about indentation.