[Python-Dev] extended if and while statements

[Luscombe Andrew]

This e-mail describes a suggestion for an extension to the "if" and "while"
statements so that programmers have an option to use them like switch
statements.  The resulting statements seem to me to read more like natural
language than similar constructs with switch statements.

The following examples illustrate the basic idea:

if book_count() ..
  == 1: purchase_9_books()
  == 2: purchase_8_books()
  <  5: purchase_5_books()
else:
  rearrange_bookshelves()


which is pretty much like a switch statement and would be logically
equivalent to the following:

nBooks = book_count()
if nBooks == 1:
   purchase_9_books()
elif nBooks == 2:
   purchase_8_books()
elif nBooks < 5:
   purchase_5_books()
else:
   rearrange_bookshelves()


and the following shows a similar thing for the while statement:

while book_count() ..
     < 10: purchase_book()
           put_book_on_shelf()
     > 20: put_in_storage( book[-1] )
           rearrange_bookshelves()


which would be logically equivalent to the following:

while 1:
     nBooks = book_count()
     if nBooks < 10:
       purchase_book()
       put_book_on_shelf()
     elif nBooks > 20:
       put_in_storage( book[-1] )
       rearrange_bookshelves()
     else:
       break


The ".." punctuation placed where a ":" would normally be indicates the
extended usage, and means that the result of the expression evaluated
immediately after the "while" or "if" will be prepended to each of the
following partial conditional statements with the first true one causing the
statements following it to be executed.  The original punctuation for "if"
and "while" statements with its original meaning would be retained.


There would be a number of options to choose in implementing the extension.
For example the ".." symbol might be a ":-" or something else.  But a more
interesting choice would be whether or not to allow an "else" within a while
loop as follows, and whether or not to continue looping when the "else" path
is taken:

while book_count() ..
     < 10: purchase_book()
           put_book_on_shelf()
     > 20: put_in_storage( book[-1] )
           rearrange_bookshelves()
     else: drink_a_beer()


perhaps by default the else path should break, but if it ends in a
"continue" then it should keep looping.  The reasoning behind this is that
due to the natural language meaning of the word "while" the loop should
repeat while one of the conditions is true, and this is not the case in the
else path.  So an else within the loop would do nothing different from an
else immediately after the while loop unless it has a continue - in which
case it would keep looping and there probably better be a break in one of
the other paths.  Of course, it would also be possible to not allow these
type of "else" statements, and then if you want such functionality you could
either make it out of separate ifs and whiles, or achieve a similar result
by using a comparison with an extreme value as the last condition, for
example: 

while book_count() ..
     < 10: purchase_book()
           put_book_on_shelf()
     > 20: put_in_storage( book[-1] )
           rearrange_bookshelves()
     > -1: drink_a_beer()

Or, you might not care about any conflict with the natural language meaning
of the word while, and just make the else path not break by default. 

Another similar choice is whether or not to have some code after the
conditional code that is executed after any of the conditional statements,
for example:

while book_count() ..
     < 10: purchase_book()
           put_book_on_shelf()
     > 20: put_in_storage( book[-1] )
           rearrange_bookshelves()
     drink_a_beer()


which would be equivalent to:

while 1:
     nBooks = book_count()
     if nBooks < 10:
       purchase_book()
       put_book_on_shelf()
     elif nBooks > 20:
       put_in_storage( book[-1] )
       rearrange_bookshelves()
     else:
       break
     drink_a_beer()


Another thing that some people might see as an issue is that a two ended
range condition with current operators and functions might not run very
efficiently.  For example

if book_count() ..
  in range(1,6):
       purchase_book()
  == 6:
       drink_a_beer()

One way around this would be if the interpreter/complier is able to
recognise such structures and compile an efficient version.  I guess it
could do this when compiling the "in" operator followed by the range()
function anywhere in the program, but then it's not really an "if" statement
issue anymore.


I've had a go at writing a formal definition of the extended statements:

if <expression1> ..
  (<expression1 result><completion of conditional expression>: <suite>)*
[else:
     <suite>]
  

while <expression1> ..
     (<expression1 result><completion of conditional expression>: <suite>)*
     [<suite>]
[else:
     <suite>]



This e-mail is only intended to be read by the named recipient. It may
contain information, which is confidential, proprietry or the subject of
legal privilege.  If you are not the intended recipient you must delete this
e-mail and may not use any information contained in it.  Legal privilege is
not waived because you have read this e-mail.