<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den ons 20 jan. 2021 kl 17:27 skrev Raimo Niskanen <<a href="mailto:raimo%2Berlang-questions@erlang.org">raimo+erlang-questions@erlang.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">1: foo(Y) -><br>
2: F = fun (Y) -><br>
3: FF = fun (Y) -><br>
4: ^Y = Y - 1<br>
5: end,<br>
6: FF(Y + 1)<br>
7: end,<br>
8: F(Y + 1).<br>
<br>
I guess that would produce warnings for shadowing on line 2 and 3.<br></blockquote><div><br></div><div>Yes, just as usual. Nothing changes there.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I guess that ^Y on line 4 refers to the Y bound on line 2.<br>
</blockquote><div><br></div><div>No, it always refers to the nearest surrounding binding, i.e., the one on line 3. If you look at the fun on line 3 in isolation: fun (Y) -> ^Y = Y - 1 end, it should be clear that ^Y in the = means the Y bound in the fun head.</div><div><br></div><div>The fundamental principle I'm trying to stick to is that the general semantics of an expression should be the same regardless of the context you might cut and paste it into. The problem with the current interpretation of "X = ..." or "case ... of X -> ..." is that it might be an equality test, or it might be a binding that always succeeds, depending on what you do with the surrounding code.</div><div><br></div><div>By saying explicitly "^X = ..." or "case ... of ^X -> ..." it becomes always a test, never a binding, no matter what else you edit. If you also ensure your code is always clean from warnings about unmarked already-bound variables, the other direction is also true: variables intended to be new in a pattern will never turn into tests by accident.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I guess that warn_unpinned_vars would not produce any warnings.<br></blockquote><div><br></div><div>In this example, no, since variables in fun heads are shadowing.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Can I match against the Y bound on line 1 from within FF/1?<br></blockquote><div><br></div><div>No, that's buried by two levels of shadowing. In the head of F on line 2 you could refer to the Y on line 1, but that's it. Even in the body of F, the outer Y would not be available.</div><div dir="ltr"><div><div dir="ltr" class="gmail_signature"><br> /Richard</div></div><div dir="ltr" class="gmail_signature"><br></div></div></div></div>