Thoughts on PEP315

[Stephen Horne]

On Mon, 22 Sep 2003 21:47:05 -0400, "John Roth"
<newsgroups at jhrothjr.com> wrote:

>
>"Stephen Horne" <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> wrote in
>message news:oalumvopu9afuhno85tbp2erl52rk9hht1 at 4ax.com...
>>
>> PEP315 (Enhanced while loop) suggests a syntax as follows...
>>
>>   do:
>>     ...
>>   while condition:
>>     ...
>
>I've snipped the rest of your lengthy analysis because I think
>the problem is much deeper, and is essentially insoluble given
>the structure of Python.
>
>The difficulty is that there is no clear and obvious way of
>distinguishing subordinate groupings from the main grouping.
>
>Consider the if statement:
>
>if something:
>    blah blah
>elif something_else:
>    blither
>else:
>    bletch
>
>If we look at this, without knowing the syntax of the
>if statement, it looks like three primary statements.
>There is no a priori way of knowing, from the lexical
>structure of the language, that elif and else cannot
>occur by themselves, but must be preceeded by
>a specific statement. You need the additional layer
>of the syntactic relationships.

I disagree. You seem to saying that the *only* relevant aspect of the
lexical structure is the use of indentation and colons. I say the use
of distinctive keywords for continuation-of-same-block-structure such
as 'elif' or 'else' is easily sufficient clarification.

The PEP315 system of...

  do:
    ...
  while condition :
    ...

is IMO broken simply because there is no lexical indicator in that
'while' line that it is a continuation rather than a new structure. It
isn't a distinctive keyword because 'while' can obviously be the start
of a loop.

'break if <condition> :', however, is lexically clear at the point
where it is written - the 'break' on itself isn't distinctive, but the
'if' following straight after makes it unambiguous that this is a
continuation of an existing loop rather than a separate break
statement.

>Consider the same structure in Ruby:
>
>if something
>    blah blah
>elsif something_else
>    blither
>else
>    bletch
>end
>
>The thing that makes all the difference is the "end"
>statement which closes the if. The elsif and the else
>are clauses within the if statement, and there is no
>way of missing that fact even if you don't know the
>exact syntax of the if structure.

If you don't know the syntax of such fundamental things as the basic
block structures in the language, you really shouldn't be reading or
writing code IMO. Especially when these are such common concepts among
languages that you should be able to understand it even if you've
never used Python, simply from experience of virtually any other
imperitive language.

>If we now go back to the loop suggestion,
>it becomes rather obvious what needs to be
>done:
>
>do:
>    bibbity
>    bobbity
>    boo
>    while condition  # note the lack of a colon!

Yuck!!!

This is really no different to the following, which is quoted in the
PEP as something to move away from...

  while True :
    ...
    if condition : break
    ...

The fundamental problem is that the exit point is not obvious because
it is 'hidden' in the detail of the loop - it is a statement within
the loop body instead of being lexically a part of the loop.

Imagine if the if statement with an else clause were written...

  if condition :
    statement;
    statement;
    statement;
    else;
    statement;
    statement;
    statement;

That is basically the situation with break at the moment - it is a
feature of the loop, but it is not lexically related to the loop. It
is IMO useful in terms of readability to make the exit point lexically
a part of the loop - to write it at the same indent level and to add
on the colon.

This is somewhat novel - I can't think of a language that does that.
Ada does have 'exit when' but it treats it as if it were any other
statement in lexical terms. Of course Ada programmers are free to put
the 'exit when' at any indentation level they like, and the approach
of matching it to the indent level of the start-of-loop line is in my
experience far from unusual.

Anyway, the thing is that just because it is unconventional doesn't
mean that it's wrong. Treating 'break' and 'continue' as just another
statement is IMO a mistake.

There is an advantage - being able to break out of the loop from a
nested structure (such as an if) but if the break is conditional
anyway, that justification mostly disappears.

>This is at least unambiguous as to what is
>going on.

I don't think 'break if' would be unambiguous. I think it would be
less unambiguous than your suggestion, in fact, for two reasons...

1.  Your suggestion is distinct from having an inner while loop *only*
    because it lacks a colon at the end of the 'while' line. That,
    IMO, is a recipe for confusion.

2.  Your suggestion has the 'while' line as a standard statement, and
    thus at the same indentation level as any other statement. When
    reading code it would be very easy to miss this loop exit point.

>I don't, by the way, think that we need this
>particular piece of syntactic sugar, regardless
>of the syntax we dress it up in.

You may be right - but the PEP still exists, has been around since
April without being rejected, and claims to be scheduled for inclusion
in 2.4.

Syntactic sugar is basically what high level languages are about -
readability and maintainability being the key benefits (though you are
free to write machine code directly in hex - to avoid the syntactic
sugar called assembler - if you really want) - but the syntax
currently described strikes me more as syntactic vinegar. An alternate
syntax proposal seems to me more of a positive way forward. Though my
record in these matters is somewhat less that 100% (around 0% in fact)
so feel free to call me an idiot.


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk