Do for loops have a second path in TIFA?

[acbart]

Currently, TIFA walks a for loop assuming that it is executed once. The comments suggest that this is a more naive approach than the original alternative, which was to walk two paths: one where the body is executed, and then one where the body is NOT executed. However, https://github.com/python-bakery/bakery-curriculum/issues/76 raises the issue that another path is possible and potentially interesting: the body is executed more than once.

A simple minimal example is as follows:

previous = 0
values = []
for i in range(1, 10):
    values.append([previous, i])
    previous = i

print(values)

Here, we have a legitimate previous variable being modified at the end of the loop, even though it is not used after the loop has finished. The reason is because that variable will be read IF there is another iteration of the loop. In practice, the previous variable should leave that loop in the maybe read state, somehow. But instead, it's leaving with the no read state, and the feedback becomes:

The variable previous was given a value on line 5, but was never used after that.

If this was like if or while, then we would construct two newPath and then use merge_paths to bring them back together. But I'm not sure it's that simple here. The reality is that there will always be a final iteration of the loop that doesn't use previous, but that's fine because it was used in prior iterations.

I have to think a lot more about what this implies conceptually, and why it's meaningful to have this kind of case. Or, rather, I need to figure out how to let the flow analyzer chill out about such cases... What about this variable makes it okay to be updated but not used the final time?

[acbart]

Insight from yesterday - it's about "meaningful" use of the variable inside of the loop. Appending to an unused list is not sufficient, but a previous variable is. Not sure how to use that insight, yet, though.

[lukesg08]

I feel like I'm missing some context from discussions happening outside this thread, but could you just hack it by assuming a loop is ran twice?

For a situation of appending to an unused list, we'd have to figure out whether a method is mutating/assigning a value as opposed to actually USING the value. E.g. append is a glorified assignment statement to a list in an over simplified context, so if we simplify append to be an assignment statement (for the sake of example here), appending to an unused list doesn't cut the criteria and should trigger the assigned but not used.

Whether that's something useful to use...well...to accommodate this, we'd have to somehow analyze EVERY function being called, which may be untenable. Might be able to simulate the loop running, see if there's change in the data, and if there is, to then consider it like you would a normal assignment statement. And then you could assume if there's no mutation in the data of the object (e.g. cloning), then you can assume it's being used. This gets really ugly when we start dealing with global variables unless we want to start tracking all changes in memory.