Of course it is decidable, the programming language has very strict rules to determine it. That's why you need language support in the editor, not just finding matching open/close delimiters.
> Of course it is decidable, the programming language has very strict rules to determine it.
No, it's not. The programming language grammar can reject things, but it cannot determine certain class of mistakes which explicit terminators ("}" and so on) can, which is why programs like `indent` existed for decades for other languages, but have yet to exist for Python which is already 30 years old.
If no one has cracked that particular nut for 30 years, you can't with a straight face claim that it is obviously possible. It looks more impossible with each passing year.
If a program cannot determine when a block code starts and ends from indentation alone, then it is not correct Python; the language needs a deterministic process to determine what sequence of commands belong to the same block, otherwise it couldn't compile.
If you're talking about failing to determine blocks which are NOT correct Python, then I don't have a problem with those failing to be correctly indented under copy/paste. The vast majority of use cases would still be well served.
We are talking about pasting code into another, where both can fail to be correct at the time and you may or may not want to output to be correct. Nonetheless, your intent can’t be determined due to multiple ambiguous “good” outputs, e.g. should insertion start at the current level and keep at it, did the copy happen from a “dumb” medium without leading whitespace so that it should be tried to be indented first, etc. Sure, you can have a look at the resulting code and fix, but we all know that humans err a lot, this is something that works braindeadly easily with non-whitespace ”aware” languages.
> If you're talking about failing to determine blocks which are NOT correct Python, then I don't have a problem with those failing to be correctly indented under copy/paste.
Then maybe you shouldn't have replied to parent who said:
>> Yes it forces clean indentation, but it gives the writer the burden to take care of it. That sucks. Let the computer do the work.
> The vast majority of use cases would still be well served.
Well, sure, because the burden for ensuring the code is correct falls onto the programmer, whereas with other languages we can just let the computer do that.
You can't let the computer ensure the correctness of code.
I replied to dismiss your assumption that adding delimiters as '}' or 'END' will ensure the correctness of code in a way that a code with indentation delimiters can't do. It's similar to saying that in, a language where statements are not finished by semicolon, it's not decidable where sentences end, so this forces the developer to decide on the correctness of statements. OF COURSE there are ways to define where a statement ends without adding a semicolon to each one, just like there are ways to decide where blocks end in an indent-based programming language; they are embedded in the language syntax.
Heck, C is notorious for producing incorrect code for NOT using meaningful indentation and relying on delimiters instead. If you write:
if (x>0)
function(1);
else
function(2);
And then you expand the else block:
if (x>0)
function(1);
else
function(2);
function(3);
Then function(3) will be compiled out of the if sentence, when it's clearly part of the else block.
> You can't let the computer ensure the correctness of code.
But I'm not letting it do that, I'm letting the computer autoformat it, which it can't do if the whitespace is the code.
> Then function(3) will be compiled out of the if sentence, when it's clearly part of the else block.
And yet, I don't have to worry about that error because the editor is able to simply autoformat it so I can see where the error is even when the compiler/interpreter thinks it's legal code!
That's the whole point - using whitespace as part of the code means that the IDE can not, and never will be able to, autoformat the code.
Your example is one of a burden that falls to the programmer in Python, but is taken care off by the computer in other languages.
These errors, which can be automatically found by the computer in other languages, have to be manually found by the programmer in Python. It's a clear disadvantage.
> But I'm not letting it do that, I'm letting the computer autoformat it, which it can't do if the whitespace is the code.
Of course it can do it. Indentation changes are parsed as delimiters, so it can treat them in the same way as if you put those delimiters yourself by hand.
> And yet, I don't have to worry about that error because the editor is able to simply autoformat it so I can see where the error is even when the compiler/interpreter thinks it's legal code!
Nothing prevents an IDE to highlight that error through other means. Ever heard of secondary notation? You don't need explicit delimiters to apply them, when indentation changes work as delimiters themselves. Simply highlight the start and end of blocks, and you'll get the same exact benefits as with programming languages based in brackets.
> These errors, which can be automatically found by the computer in other languages,
So tell me, how would the computer find an error if you have unmatched open/closed brackets? Doesn't that mean that other computer languages have errors that can't exist in Python?
> Your example is one of a burden that falls to the programmer in Python, but is taken care off by the computer in other languages.
How does an error in C code fall to the programmer of Python?
BTW, do you understand Python block delimiters at all? Your complaint seems to come from not understanding how a Python developer sees indentation. Once you enter this mindset, indentation errors are no different than unmatched open/close brackets - which do exist in languages like C too.
> That's the whole point - using whitespace as part of the code means that the IDE can not, and never will be able to, autoformat the code.
No - it means that indentation changes are meaningful, so the state of the code before reformatting should be maintained after reformatting. As long as the reformat tool doesn't change the meaning of the Python code, it will autoformat code perfectly fine, as numerous autoformatters in existence prove.
Which is what I was referring to in my first comment - you need an IDE that understands Python syntax, not just one that blindly pairs open/close delimiters.
One more thing you should consider in your argumentation is, that in non-whitespace-sensitive languages the programmer can make fewer mistakes when pasting code:
It could be pasted at a completely wrong position of course, before some other expression or after some other expression, where it should not be. Aside from that however, the programmer cannot make a mistake by pasting it in a place, that is between 2 expressions, because that is one potentially huge correct position to paste that code. It stretches from the end of one expression to the beginning of the other expression. Anywhere in between the programmer can paste code.
In contrast to that in Python and other whitespace-sensitive language, one has to be very careful about where to paste. Only in the case of pasting at the semantically correct indentation level (basically one tiny position in the code) can the editor/IDE/tool know how to indent things. Of course humans make mistakes and paste maybe 1 space to the left or right or even a whole indentation left or right of the correct position and then the tool cannot help you make your code do the right thing. It could be valid code, accepted by the compiler or interpreter, but still semantically wrong, doing something you did not want it to do.
The tool cannot fix the pasting at wrong position mistakes made by humans in all generality, because it does not know the actual intention and it can be ambiguous what the result should be.
I hope this makes a long discussion a bit clearer.
No; it is not decidable where a block ends and the next line of the out block starts when there is no marker for block ends ('}', or 'END', etc).