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.