[Python-ideas] If branch merging

[Nick Coghlan]

On 8 June 2015 at 23:21, Andrew Barnert <abarnert at yahoo.com> wrote:
> On Jun 8, 2015, at 05:26, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> The problem with a let expression is that you still end up having to
>> jumble up the order of things, just as you do with the trick of
>> defining and calling a function, rather than being able to just name
>> the subexpression on first execution and refer back to it by name
>> later rather than repeating the calculation.
>
> But notice that in two of your three use cases--and, significantly, the ones that are expressions--the place of first execution comes lexically _after_ the reference, so in normal reading order, you're referring _forward_ to it by name.

Right, but as you note later, that jumping around in execution order
is inherent in the way conditional expressions and comprehensions are
constructed, and the named subexpressions track execution order rather
than lexical order. It's also worth noting that the comprehension case
causes the same problem for a let expression that "pull it out to a
separate statement" does for while loops:

    # This works
    x = a.b
    if x:
        # use x

    # This doesn't
    x = a.b
    while x:
        # use x

And similarly:

    # This could work
    x = (let b = a.b in (b if b else a.c))

    # This can't be made to work
    x = (let b = a.b in (b for a in iterable if b)

By contrast, these would both be possible:

    x = b if (a.b as b) else a.c
    x = (b for a in iterable if (a.b as b))


If it's accepted that letting subexpressions of binary, ternary and
quaternary expressions refer to each other is a desirable design goal,
then a new scope definition expression can't handle that requirement -
cross-references require a syntax that can be interleaved with the
existing constructs and track their execution flow, rather than a
syntax that wraps them in a new larger expression.

> He can front a clause without swapping the pronoun and its referent if Nick intends that special emphasis, but otherwise he wouldn't do that in English. That's a valid English sentence, but you have to think for a second to parse it, and then think again to guess what the odd emphasis is supposed to connote.

Yeah, I didn't adequately think through the way the out-of-order
execution weakened the pronoun-and-back-reference analogy.

> Sometimes you actually do want that odd emphasis (it seems like a major point of your given proposal),

It's just a consequence of tracking execution order rather than
lexical order. The *reason* for needing to track execution order is
because it's the only way to handle loops properly (by rebinding the
name to a new value on each iteration).

It's also possible to get a conditional expression to use a back
reference instead of a forward reference by inverting the check:

    x = a.c if not (a.b as b) else b

Or by using the existing "pull the subexpression out to a separate
statement" trick:

    b = a.b
    x = b if b else a.c

You'd never be *forced* to use a forward reference if you felt it made
the code less readable.

The forward reference would be mandatory in comprehensions, but that's
already at least somewhat familiar due to the behaviour of the
iteration variable.

> but that's not the case here. It's the temporary name "b" that's unimportant, not its definition; the only reason you need the name at all is to avoid evaluating "a.b" twice. So having it come halfway through the expression is a little weird.

I'd consider elif clauses, while loops, comprehensions and generator
expressions to be the most useful cases - they're all situations where
pulling the subexpression out to a preceding assignment statement
doesn't work due to the conditional execution of the clause (elif) or
the repeated execution (while loops, comprehensions, generator
expressions).

For other cases, the semantics would need to be clearly *defined* in
any real proposal, but I would expect a preceding explicit assignment
statement to be clearer most of the time.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia