allow line break at operators

[Steven D'Aprano]

Seebs wrote:

> I guess... The parser is explicitly pushing those tokens, but I can't
> *SEE* those tokens.  If I am looking at the end of a really long
> thing, and I see:
> 
>                         blah
>         blah
> 
> I only know what's happening if I have absolute confidence that the
> indentation is always by the same amount, etectera.

I believe this is a dubious argument. With only two lines of code in
isolation, understanding the indentation changes is the least of your
worries. Adding block delimiters doesn't give you any significant help --
ESPECIALLY if the block delimiters don't align with the indentation!

                        blah
 }
        blah
                                }


In isolation, you don't even know whether the above is syntactically valid,
since you have no way of knowing that either end brace is closing an open
brace or not. 

"Who would write such a horrible mis-aligned piece of code?" Good question.
If you're going to have style-guides that prohibit writing code like the
above, then what exactly do the braces give you?

Yes, yes, if you paste the code into a web forum the indentation may
disappear, and if your hard drive controller is faulty it may randomly
overwrite blocks with data belonging to other files. We all agree that
environments that destroy data are Bad.


>> Yet another reason to consider brace languages harmful: they spoil the
>> user's intuitive grasp of intuition as grouping.
> 
> I assume you mean "indentation as grouping".

Yes, sorry about that.


> I'm... not sold on this.  It's not that I don't see indentation as a kind
> of grouping.  It's just that I really, really, want groups to have ends.
> 
> Consider the hypothetical array syntax:
> 
>         a = [
>             1,
>             2
>         b = [
>             3,
>             4
>
> This *bugs* me.  It's perfectly legible, and if you define it that way,
> it's
> unambiguous and everything, but... It bugs me.  I want beginnings to have
> an actual corresponding end.

Do you get worried by books if the last page doesn't include the phrase "The
End"? These days, many movies include an extra clip following the credits.
When the clip finishes, and the screen goes dark, how long do you sit
waiting before you accept that the movie is over?

*wink*

The above example bugs me too, because it is too close to what I'm used to
in Python. I see an open bracket, I wait for a close bracket. Perhaps this
would be better:

a = array 
    1, 
    2,
b = array 
    3, 
    4,

Not so bad now, I betcha. And you can nest arrays:

c = array 
    5, 
    6,
    array
         7,
         8,
    9,

Now, I wouldn't actually recommend such a syntax for a programming language.
(Maybe for a config file format?) It's too big and awkward for array
literals in an expression. You can partly fix that by making the whitespace
optional, allowing an array to be written on one line:

a = array 1, 2
b = array 3, 4

but that screws up the ability to nest arrays. Also, what happens here?

spam(a, b, array 5, 6)

That's ambiguous -- does spam have three arguments or four? Again, easy
enough to fix:

spam(a; b; array 5; 6)  # four args

but you still can't nest arrays. This potential syntax doesn't feel like a
unified whole, but like a bunch of unrelated fixes for problems. Sometimes
a literal START and END delimiter is the right answer.

Python's use of indentation to delimit blocks doesn't feel like that. Unlike
arrays, you can't use blocks in an expression, and I think that's the
factor which makes all the difference. Ruby folks may call the lack of
block expressions a problem with Python, but even if they're right, I don't
think it's a *big* problem. Either way, given the restriction that blocks
are statements, not expressions, the lack of an overt block markers is not
a problem for code (with the proviso that a rogue editor doesn't go making
arbitrary changes to your source code).



-- 
Steven