10 days later... sorry, I didn't see your comment. The example I gave had a few pieces: - x is defined prior to the if/else, and overwritten in just one branc

10 days later... sorry, I didn't see your comment. The example I gave had a few pieces: - x is defined prior to the if/else, and overwritten in just one branch - y is defined in both branches So in the rest of the function, we have both x and y available, regardless of which branch is taken. I just took a quick read of the context page and the context basics page, but it's still unclear to me whether you can program how scopes/contexts interact in rye. In my example, we I'd say we have a few different scopes worth mentioning, and I'm curious how programmably we can make them interact in rye: Scope 1. Right below the first x = ...: we have names available form <beginning of the function> and have x available as the ... stuff. Presumably the `foo` in `if foo` lives in this scope. Scope 2T. Right after the true branch's y, we have scope 1 plus y introduced Scope 2F. Right after the false branch's x and y, we have scope 1 plus x "pointing to" something new and y introduced. Scope 3. Below the if/else, where <rest of the function> lives. This is either scope 2T or scope 2F. x is either scope 1's x or scope 2F's x, and y is either scope 2T's y or 2F's y. In the original articles language, So the scope relationships in an if/else are a diamond DAG taking the names from before it, making them available in each branch's scopes, and then making a sorta disjoint union of the branch's names available afterwards. Could that be programmed in rye, to allow the kinds of naming ergonomics in my previous example, but with the if/else being programmable in the sense of the original article? I'm especially interested in whether we could overload it in the traditional autodiff sense. Responding to a different part of your comment about using names rarely in rye, I've found that I benefit a ton from handing out names more than most people do in functional languages, just for clarity and more self-documenting code. Like, the ide can say "`apples` is broken" instead of "error in location xyz" and I can rebuild my mental state better too when revisiting code.