[bmandale]

> I would love to see a language try to implement a rule where only an indented line is considered part of the previous expression.

After python, it seems like every language decided that making parsing depend on indents was a bad idea. A shame, because humans pretty much only go by indents. An example I've frequently run into is where I forget a closing curly brace. The error is reported at the end of the file, and gives me no advice on where to go looking for the typo. The location should be obvious, as it's at exactly the point where the indentation stops matching the braces. But the parser doesn't look at indents at all, so it can't tell me that.

[stinkbeetle]

> An example I've frequently run into is where I forget a closing curly brace. The error is reported at the end of the file, and gives me no advice on where to go looking for the typo. The location should be obvious, as it's at exactly the point where the indentation stops matching the braces. But the parser doesn't look at indents at all, so it can't tell me that.

That's somewhat a quality of service issue though. Compilers should look at where the braces go out of kilter vs indentation and suggest the possible unmatched opening brace.

[kayson]

I was much more opposed to this early on than I am now. With modern IDEs and extensions handling tabs vs spaces, tab width, and formatting, python ends up being very easy to read and write. I use it daily, and while I hate it for other reasons, I can't remember the last time I had any issues with indentation.

[notepad0x90]

I must disagree but only a tiny bit. modern IDEs try to indent and attempt to add indentation as you code which can cause problems sometimes.

tabs vs spaces is very painful still when copying code that is in a different format. it's not just tabs and spaces, but the width of the tabs and the spaces. Even with VSCode extensions and sublime text extensions I've struggled a lot recently with this.

I commented on a sibling thread just now, but it is still very easy in python to mess up one level of indentation. When I caught bugs of that sort, it was introduced either when copy pasting, when trying to make a linter happy and doing cosmetic cleanup, or when moving code around levels of indentation, like introducing a try/except. I had one recently where if I recall correctly I moved a continue statement under or out of a try/except when messing around with the try/except logic. it was perfectly valid, and didn't stand out much visually, pydnatic and other checkers didn't catch it either. It could have happened with a '}' but it's easier to mess up a level of indentation than it is to put the '}' at the wrong level. a cosmetic fix results in a logic bug because of indentations in python. with curly's, a misplacement of that sort can't happen because of indentation or cosmetic/readability fixes.

what the curly approach asserts is a separation of readability and logic syntax.

The interpreter/compiler should understand your code first and foremost, indenting code should be done, and should be enforced, but automatically by the compiler/interpreter. Python could have used curly braces and semi-colons, and force-indented your code every time it ran it to make it more readable for humans.

[notepad0x90]

we don't even use indents that way in natural language. We use things like bullet points, we need specific markers.

space is for spacing, tabs are for tabulation, they are not in any human language I know of used as terminators of statements. You know what is the equivalent of an indent or a semicolon in english? a period. <-

We have paragraph breaks just like this to delimit blocks of english statements.

A semi-colon is used to indicate part of a sentence is done, yet there is still related continuation of the statement that is yet to be finished. Periods are confusing because they're used in decimal points and other language syntax, so a semi-colon seems like a good fit.

If I had my pick, I would use a colon to indicate the end of a statement, and a double colon '::' to indicate the end of a block.

func main(): int i - 0: do: i=i+1: print(i): while(i<10):: ::

another downside of indentation is it's award to do one-liners with such languages, as with python.

There is a lot of subjectivity with syntax, but python code for example with indents is not easy for humans to read, or for syntax validators to validate. it is very easy for example to intend a statement inside a for loop or an if/else block in python (nor not-intend it), and when pasting around code you accidentally indent one level off without meaning to. if you know to look for it, you'll catch it, but it's very easy to miss, since the mis-indented statement is valid and sensible on its own, nothing will flag it as unusual.

In my opinion, while the spirit behind indentation is excellent, the right execution is in the style of 'go fmt' with Go, where indenting your code for you after it has been properly parsed by the compiler/interpreter is the norm.

I would even say the first thing a compiler as well as interpreter do should be to auto-indent, and line-wrap your code. that should be part of the language standard. If the compiler can't indent your code without messing up logic or without making it unreadable, then either your code or the language design has flaw.

[xigoi]

> we don't even use indents that way in natural language.

Have you never seen a nested table of contents?

  1. Introduction
  2. Fruit
    2.1 Apples
      2.1.1 Red apples
      2.1.2 Green apples
    2.2 Oranges
  3. Vegetables
    3.1 Carrots

[notepad0x90]

with apples in that list for example, you used '2.1' to indicate a new item, the space is cosmetic, the functional indicator is '2.1'

This wouldn't look right:

Introduction

  Fruit

    Apples

      Red apples

      Green apples

I'm sure you can work it out, but it doesn't feel natural, or ideal. (i can't get hn to format it without making it all one line so i used double new line).

[lelanthran]

Your example remains valid after the indentation is stripped, because it has markers to delineate the list and sub list items.

[xigoi]

It doesn’t need to; that’s just the section numbering. In a biology textbook, you could have something like (made up names)

  Arabateciae
    Arabaticopoda
    Arabaticoquasicae
  Bidoroca
    Pseudobidoroca
    Superbidoroca
      Superduperbidoroca

and the hierarchy is still clear.

[notepad0x90]

it would look better still with a dash or a bullet point for every sub-entry. We're not arguing that it is possible to do that, we're arguing what is ideal for readability.

In that list you can naturally guess what that ordering is, but if the items were not so interrelated it can be confusing. if the top level item is 'Ham' and the indented item under it is 'sandwich' are you wrapping the same phrase 'Ham Sandwich' , because indentation (even in python) is used when wrapping lines, or is sandwich under ham as one of the things done with ham. it is thus error-prone and more confusing, clear and specific punctuation alongside indentation makes it easier to read.

[lelanthran]

No one is saying that indentation can not be used to display lists/sublists, I'm saying that markers remove ambiguity even across movement of blocks of texts.

Indentation is fragile.

[Blikkentrekker]

The issue is that you find you very often want to break those roles. Python basically has `elif` because `else if` would make each branch nest one level deeper which isn't what one wants, except Python uses exceptions for flow control so you find yourself having to use `except ... try` as an analogue to `else if` but not `excetry` exists to do the same and stop the indentation.

There are many other examples. It exists to give people freedom. Also, while humans only go by intendation it's very hand for text editing and manipulation without requiring special per-language support to move the cursor say to the nearest closing brace and so forth.

[XorNot]

I'm very okay with elif though because it makes it clear that the conditional is part of the chained block and not a brand new one.

[Blikkentrekker]

The issue is that it's a special case that acknowledges where there are cases where the indentation level it logically requires isn't what programmers find pleasant, there are many more, that just don't have that special case, so it forces indentation that's unpleasant and unintuitive.

[Joker_vD]

> Python basically has `elif` because `else if` would make each branch nest one level deeper which isn't what one wants

There are, of course, other ways to handle this. For instance, "else if <cond>:" could've been made legal à la Golang:

    IfStmt = "if" [ SimpleStmt ";" ] Expression Block [ "else" ( IfStmt | Block ) ] .

[lelanthran]

What language is this? In C I get the correct position of the error because GCC also monitors the indentation as it parses.

A linter can point out errors based on indentation, and they frequently do. There's no need for the language to do it and then band-aid additional fixes for problems caused by significant white space.

[estebank]

rustc does exactly that keeping the indent level of every unbalanced curly brace. It works OK, but it isn't perfect by any stretch. More heuristics are needed.

[vips7L]

Scala 3 decided to go with indents.

[elfly]

You are not telling the whole story.

You can mix indentation and braces to delimit blocks.

It's insane.

[macintux]

As a casual observer who has written perhaps a dozen lines of Scala in his life, I feel like Scala approaches any “pick one” decision with “why not both?”.

Functional or OO? Yes.

[Blikkentrekker]

I like how Haskell does it. One can do both but not mix, as in either indent or use `{ ... }`.

[vips7L]

I personally think this put the final nail in the coffin.

[Pay08]

Kind of. It supports an end operator as well, and imo everyone should be using it. I actually really like the `end name` approach as opposed to the Lua-style plain ends.