PEP 308: Alternative conditional operator forms -- Corner Case solved

[Andrew Koenig]

Erik> I'm going to turn that one right around on you.  Why add the new
Erik> keyword `ifelse'?  Why not use `if'?

John> Because you've got a major ambiguity if the statement begins
John> with an "if". That comment is in the PEP.

I believe I have eliminated the ambiguity.

Many people have suggested that it requires unbounded lookahead to
determine whether

        if C: expr1 else: expr2

is a statement or an expression.  After thinking about it for a while,
I suddenly realized that this claim is not true.

The key here is that a statement always ends with either a newline
or a dedent, and an expression never does.  That means that when
you're parsing bottom-up, whenever it comes time to determine whether
a construct is an expression or a statement, you can always make that
determination by seeing whether the next symbol is a newline, a dedent,
or something else.

This surprising fact yields an even more surprising simplification
of my previous proposal for changing the grammar:

        Original:

        test: and_test ('or' and_test)* | lambdef

        Proposed:

        test: and_test ('or' and_test)* | lambdef | if_test
        if_test: 'if' test ':' test ('elif' ':' test)* 'else' ':' test

In English: An if-else expression is permitted anywhere a lambda
expression is permitted, with the same precedence rules.

This change passes pgen without complaint.

Some implications:

    if x==0: "foo" else: "bar"                # legal expression

    if x==0: "foo"                            # legal statement
    else: "bar"

    print if x==0: "foo" else: "bar"          # legal statement

    if x==0: print "foo" else: print "bar"    # illegal, as it is today--
                                              # print is not an expression

    if x==0: print "foo"                      # legal statement, as it is today
    else: print "bar"

    if x==0: "foo"                            # legal statement, as it is today
    else: "bar"

-- 
Andrew Koenig, ark at research.att.com, http://www.research.att.com/info/ark