[Python-ideas] If branch merging

[Steven D'Aprano]

On Sat, Jun 06, 2015 at 09:03:38PM -0600, Cory Beutler wrote:

[...]
> This would simplify some logic expressions by allowing the merging of
> branched code.
> 
> *Examples of use:*
> *Duplicate code in if-chains may be reduced:*
> # Old Version
> if a == b:
>     print ('a == b')
>     foo()             # <-- duplicate code
> elif b == c:
>     print ('b == c')
>     foo()             # <-- duplicate code
> elif c == d:
>     print ('c == d')
>     foo()             # <-- duplicate code

if a == b:
    print('a == b')
elif b == c:
    print('b == c')
elif c == d:
    print('c == d')
foo()

No new syntax required.


> *Many nested 'if' statements could now be a more linear style:*
> # Old Version
> if a == b:
>     print ('a == b')
>     if b == c:
>         print ('b == c')
>     print ('end if')

What's wrong with that code? Nesting the code like that follows the 
logic of the code: the b==c test *only* occurs if a==b.


> # New Version
> if a == b:
>     print ('a == b')
> alif b == c:
>     print ('b == c')
> also:
>     print ('end if')

I consider this significantly worse. It isn't clear that the comparison 
between b and c is only made if a == b, otherwise it is entirely 
skipped.


> These two examples are the most common ways this will help code. I have
> been writing code samples using these keywords and have found that it
> simplifies many other things as well. It does take a bit of getting used
> to, though. I have found that is is best to use 'also' and 'alif'
> sparingly, as overuse can make some code less flexible and more confusing.

You don't say.

Are you aware of any languages with this construct?

What are the rules for combining various if...elif...alif...also...else 
blocks?



> *Selective Branch merging:*
> One limitation of the 'also' and 'alif' keywords is the restriction to the
> "all of the above" checking. What I mean by that is that there is no way to
> pick and choose which branches to merge back together. When using 'also'
> and 'alif' you are catching all previous if-branches. One easy way to solve
> this would be to allow for named branching. The most simple way to do this
> is to save the conditions of each branch into a variable with a name. Here
> is an example of merging only select branches together:
> # Old Version
> if a == b:
>     print ('a == b')
> elif a == c:
>     print ('a == c')
> elif a == d:
>     print ('a == d')
> if (a == b) or (a == d):
>     print ('a == b and a == d')

That code is wrong. Was that an intentional error? The final branch 
prints that a == b == d, but that's not correct, it runs when either 
a == b or a == d, not just when both are true.

Personally, I would write that as:

if a == b or a == d:
    if a == b:
        print('a == b')
    else:
        print('a == d')
    print('a == b or a == d')
elif a == c:
    print('a == c')

You do end up comparing a and b for equality twice, but worrying about 
that is likely to be premature optimization. It isn't worth adding 
syntax to the language just for the one time in a million that actually 
matters.


> # New Version using 'as' keyword
> if a == b as aisb:
>     print ('a == b')
> elif a == c:
>     print ('a == c')
> elif a == d as aisd:
>     print ('a == d')
> alif aisd or aisb:
>     print ('a == b and a == d')

With this "as" proposal, there's no need for "alif":

if a == b as aisb:
    print('a == b')
elif a == c:
    print('a == c')
elif a == d as aisd:
    print('a == d')
if aisd or aisb:
    print('a == b or a == d')


I think this has been proposed before. 


[...]
> I realize that using the 'as' keyword may not be the best. Using 'as' seems
> to suggest that it will only be used in the following block.

Not necessarily. Consider "import module as spam".


[...]
> I am currently working with ansi C to
> try to get something similar into the 'C' language, but it could be 20
> years before anything comes of that. The gears move ofly slow over there.

One advantage of Python is that the language does evolve more quickly, 
but still, Python is a fairly conservative language. We don't typically 
add new syntax features unless they solve a problem in an elegant 
fashion that cannot be solved easily without it.

-- 
Steve