QoL: if parser should accept known symbols for its case

[liamhuber]

Like

import flowrep as fr

def identity(x):
    return x

@fr.workflow
def macro(x, y, z):
    if x:
        w = identity(y)
    else:
        w = identity(z)
    return w

Currently you need an identity wrapper like if identity(x).

Under the hood, the recipe still expects an operation for the case, and I can tolerate that, I'd be content if it just auto-inserted the identity operation at parsing time so I can write more straightforward python.

[samwaseda]

Do I understand correctly that you are talking about the condition x being a global input parameter instead of being the output of a node? That sounds ok to me

[liamhuber]

Ah, no, I hadn't meant to be as bold as that. I was talking only about modifying the parser so that

@flowrep.workflow
def wf(x, cond):
    if cond:  # Not a function call!
        y = foo(x)
    else:
        y = x
    return y

Can be parsed, and is equivalent to the identical but slightly more verbose

@flowrep.workflow
def wf(x, cond):
    if identity(cond):  # Trivially coerce to function call
        y = foo(x)
    else:
        y = x
    return y

Directly parsing the conditional as an input to IfRecipe is an interesting idea, but I would advise against it. Were we to do that, we would need some way to indicate which input is the critical condition input (and it would need to be extensible to an arbitrary number of elifs). The two ways I can think to do that are to have it be positionally implicit (i.e. the first $n$ or last $n$ inputs are the condition inputs) or pattern-matching implict (i.e. ports with a certain naming pattern like "condition_*" are interpreted as the condition inputs).

In both those cases, we are constraining recipe values, i.e. what is to the right of the colon in inputs: [...]. This would be new and unique. Apart from the requirement on labels being python symbol-like + not hitting our exclusion list, I can think of nowhere else that we make constraints on values in the recipes. Rather, we indicate special behaviour by the presence of special fields. In this case, cases: and else_case:.

So I find it a neat idea, but I don't immediately see a way for it to line up well with how any of the other nodes currently function, and it moves in the direction of implicit rules vs the status quo of explicit fields that need to be populated.

[samwaseda]

ok and I guess we are still talking about the same thing, and yes, I think it sounds fine to me 👍

[liamhuber]

Super. It's not super high priority for me, but if I can get it done with sufficiently little overhead in the parser I'll go for it.