On Tuesday 24 January 2017 13:38, Chris Angelico wrote:
> On Tue, Jan 24, 2017 at 12:47 PM, BartC <b...@freeuk.com> wrote:
>> Take the same code with block
>> delimiters, and take out that same indent:
>>
>> if 0 then
>> print ("one")
>> print ("two")
>> endif
>> print ("three")
>>
>> It still compiles, it still runs, and still shows the correct "three" as
>> output.
>
> My point is that you *assume* that showing just "three" is the correct
> behaviour. Why? Why do you automatically assume that the indentation
> is wrong and the endif is correct? All you have is that the two
> disagree.
It's Bart's special language, so the correct behaviour is whatever he says it
is :-)
But more seriously, it's easy to typo an extra indent. It's harder to typo
"endif" when you actually meant to type, oh, "ending = 1 if condition else 3",
say. So faced with ambiguity, and the insistence that the right way to break
ambiguity is to guess ("Do What I Mean, dammit!!!") the most likely guess is
that the indentation is wrong.
But not guaranteed. That's the thing about being ambiguous -- there is a chance
that the indentation is correct.
This *especially* applies to languages like C, when open/close delimiters
optional if the block is only a single statement, and where the delimiters are
only a single character.
And sure enough, C is prone to indent/brace mismatch errors.
When I design my killer language, it won't fail when there's a mismatch between
indentation and open/close delimiters. Nor will it just give priority to one or
the other. Instead, it will learn from your errors and typos in order to
determine which you are statistically more likely to want, and silently compile
the code that way. But without changing the source code, of course.
--
Steven
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." - Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
