<div dir="ltr"><div dir="ltr"><div>Hi!<br></div><div><br></div><div>So for better or worse I also want to share my view of the "pinning operator"<br></div><br><div>I work for the OTP team, but the opinions I am about to share are my own. The
pinning operator, or actually annotation, has turned out to be very
controversial and although I can see some arguments for it I still feel very unconvinced I like to see it in Erlang. I will try to explain some
of my concerns.</div><div><br></div><div>Before I started working for
the OTP team I worked as an Erlang consultant and teacher. When teaching
Erlang I would tell my students that to program Erlang/OTP they need to
change their mindset from when programming in imperative or object
oriented languages. There are some things that are central to Erlang
programs that are different and it is pattern matching and single
assignment, recursion being a very common way to solve the problem and
how you think about concurrency. <br></div><div><br></div><div>One of
my coworkers checked how many matches were done in the OTP source code
as in comparison to our test suites. And there were actually more
matches in the source code. I think this is a result of how most Erlang
programmers solve problems the "Erlang way". Also this is not counting
all the matches done in function clauses where the annotation makes no
sense (and hence is not included in the "pinning"). So with pinning we
will have two ways of matching depending on where we match. <br></div><div><br></div><div>Now
the EEP proposal does not allow rebinding of variables, but let's face
it that would be the next step. Especially when that is part of why
Elixir needs to have a "pinning operator". And it is argued that we
should have the ^ to resemble Elixir. Now I am not saying we should
allow variable rebinding, but in the case that we would, I think that
the rebinding should be the thing annotated. Because rebinding should be
the exception and the matching should be the default. <br></div><div><br></div><div>I think it is human to consider too little of the context and alas the compiler will never
be able to catch all the times, we also have to rely on regression
tests for instance. How many times have not a feature development or bug fix involved fixing some other test that happend to break. <br></div><div><br></div><div>So we will see what happens. I think there are still many things to consider.<br></div><div><br></div><div><div>Regards Ingela<br></div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den ons 20 jan. 2021 kl 15:42 skrev Raimo Niskanen <<a href="mailto:raimo%2Berlang-questions@erlang.org" target="_blank">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">I have vague feeling that this has been asked,<br>
but since I can not find it:<br>
<br>
How is nested fun()s handled?<br>
<br>
foo(Y) -><br>
F = fun (X) -><br>
Y = X + ^Y,<br>
FF = fun (Z) -><br>
Z + ^Y<br>
end,<br>
FF(Y)<br>
end,<br>
F(Y).<br>
<br>
Does the innermost Z + ^Y access the outermost Y from foo(Y), or the Y<br>
bound in F/1 i.e Y = X + ^Y?<br>
<br>
Is there a way to choose which of the outer Y:s to refer to from within FF/1?<br>
<br>
Cheers<br>
/ Raimo<br>
<br>
<br>
<br>
On Thu, Dec 24, 2020 at 09:10:17PM +0100, Richard Carlsson wrote:<br>
> The ^ operator allows you to annotate already-bound pattern variables as<br>
> ^X, like in Elixir. This is less error prone when code is being refactored<br>
> and moved around so that variables previously new in a pattern may become<br>
> bound, or vice versa, and makes it easier for the reader to see the intent<br>
> of the code.<br>
> <br>
> See also <a href="https://github.com/erlang/otp/pull/2951" rel="noreferrer" target="_blank">https://github.com/erlang/otp/pull/2951</a><br>
> <br>
> Ho ho ho,<br>
> <br>
> /Richard & the good folks at WhatsApp<br>
<br>
> Author: Richard carlsson <carlsson.richard(at)gmail(dot)com><br>
> Status: Draft<br>
> Type: Standards Track<br>
> Created: 21-Dec-2020<br>
> Erlang-Version: 24<br>
> Post-History: 24-Dec-2020<br>
> ****<br>
> EEP XXX: Pinning operator ^ in patterns<br>
> ----<br>
> <br>
> <br>
> Abstract<br>
> ========<br>
> <br>
> This EEP proposes the addition of a new unary operator `^` for<br>
> explicitly marking variables in patterns as being already bound. This<br>
> is known as "pinning" in Elixir - see [Elixir doc][the Elixir<br>
> documentation].<br>
> <br>
> For example:<br>
> <br>
> f(X, Y) -><br>
> case X of<br>
> {a, Y} -> ok;<br>
> _ -> error<br>
> end.<br>
> <br>
> could be written more explicitly:<br>
> <br>
> f(X, Y) -><br>
> case X of<br>
> {a, ^Y} -> ok;<br>
> _ -> error<br>
> end.<br>
> <br>
> In Elixir, this operator is strictly necessary for being able to refer<br>
> to the value of a bound variable as part of a pattern, because<br>
> variables in patterns are always regarded as being new shadowing<br>
> instances (like in Erlang's fun clause heads), unless explicitly<br>
> pinned.<br>
> <br>
> In Erlang, they would be optional, but are still a good idea because<br>
> they make programs more robust under edits and refactorings, and<br>
> furthermore allow the use of pinned variables in fun clause heads and<br>
> in comprehension generator patterns.<br>
> <br>
> <br>
> Specification<br>
> =============<br>
> <br>
> A new unary operator `^` is added to Erlang, called the "pinning<br>
> operator". It may only be used in patterns, and only on variables.<br>
> Its meaning is that the "pinned" variable is to be interpreted in the<br>
> enclosing environment of the pattern, and its value used in its place<br>
> for that position in the pattern.<br>
> <br>
> In current Erlang, this behaviour is what happens automatically in<br>
> ordinary matching constructs if the variable is already bound in the<br>
> enclosing environment. In the following example:<br>
> <br>
> f(X, Y) -><br>
> case X of<br>
> {a, Y} -> {ok, Y};<br>
> _ -> error<br>
> end.<br>
> <br>
> the use of `Y` in the pattern is regarded as a reference to the<br>
> function parameter `Y`, instead of as introducing a new variable, and<br>
> the `Y` in the clause body is then that same parameter. Therefore,<br>
> annotating the pattern variable as `^Y` in this case does not change<br>
> the behaviour of the program, but makes the intent explicit:<br>
> <br>
> f(X, Y) -><br>
> case X of<br>
> {a, ^Y} -> {ok, Y};<br>
> _ -> error<br>
> end.<br>
> <br>
> For fun expressions and list comprehension generator patterns, the<br>
> pinning operator makes the language more expressive. Take the<br>
> following Erlang code:<br>
> <br>
> f(X, Y) -><br>
> F = fun ({a, Y}) -> {ok, Y};<br>
> (_) -> error<br>
> end,<br>
> F(X).<br>
> <br>
> Here, the occurrence of `Y` in the clause head of the fun `F` is a new<br>
> variable instance, shadowing the `Y` parameter of `f(X, Y)`, and the<br>
> fun clause will match any value in that position. The `Y` in the<br>
> clause body is the one bound in the clause head. However, using the<br>
> pinning operator, we can selectively match on variables bound in the<br>
> outer scope:<br>
> <br>
> f(X, Y) -><br>
> F = fun ({a, ^Y}) -> {ok, Y};<br>
> (_) -> error<br>
> end,<br>
> F(X).<br>
> <br>
> In this case, there is no new binding of `Y`, and the use of `Y` in<br>
> the fun clause body refers to the function parameter. But it is also<br>
> possible to combine pinning and shadowing in the same pattern:<br>
> <br>
> f(X, Y) -><br>
> F = fun ({a, ^Y, Y}) -> {ok, Y};<br>
> (_) -> error<br>
> end,<br>
> F(X).<br>
> <br>
> In this case, the pinned field refers to the value of the function<br>
> function parameter, but there is also a new shadowing binding of `Y`<br>
> to the third field of the tuple. The use in the fun clause body now<br>
> refers to the shadowing instance.<br>
> <br>
> Generator patterns in list comprehensions or binary comprehensions<br>
> follow the same rules as fun clause heads, so with pinning we can for<br>
> example write the following code:<br>
> <br>
> f(X, Y) -><br>
> [{b, Y} || {a, ^Y, Y} <- X].<br>
> <br>
> where the `Y` in `{b, Y}` is the shadowing instance bound to the third<br>
> element of the pattern tuple.<br>
> <br>
> Finally, a new compiler flag `warn_unpinned_vars` is added, disabled<br>
> by default, which if enabled makes the compiler emit warnings about<br>
> all uses of already bound variables in patterns that are not<br>
> explicitly annotated with the `^` operator. This allows users to<br>
> migrate their code module by module towards using explicit pinning in<br>
> all their code. If pinning becomes the norm in Erlang, this flag<br>
> could be turned on by default, and eventually, the pinning operator<br>
> could become strictly required for referring to already bound<br>
> variables in patterns.<br>
> <br>
> <br>
> Rationale<br>
> =========<br>
> <br>
> The explicit pinning of variables in patterns make programs more<br>
> readable, because the intent of the code becomes clear. When already<br>
> bound variables are used in Erlang without any annotation, anyone<br>
> reading a piece of code must first study it closely to understand<br>
> which variables will be bound at the point of a pattern, before they<br>
> can tell whether any pattern variable is a new binding or implies an<br>
> equality assertion. This is easy to miss even for experienced<br>
> Erlangers, be it during code reviews or while trying to understand a<br>
> piece of poorly commented code.<br>
> <br>
> Perhaps more importantly, pinning also makes programs more robust<br>
> under edits and refactorings. Take our previous example, and add a<br>
> print statement:<br>
> <br>
> f(X, Y) -><br>
> io:format("checking: ~p", [Y]),<br>
> case X of<br>
> {a, Y} -> {ok, Y};<br>
> _ -> error<br>
> end.<br>
> <br>
> Suppose someone renames the function parameter from `Y` to `Z` and<br>
> updates the print statement but forgets to update the use in the case<br>
> clause. Without an explicit pinning annotation, the change would be<br>
> quietly allowed, but the `Y` in the pattern would be interpreted as a<br>
> new variable that will match any value, which will then be used in the<br>
> body. This changes the behaviour of the program. If the use in the<br>
> pattern had been annotated as `^Y`, the compiler would have generated<br>
> an error "Y is unbound" and the mistake would have been caught.<br>
> <br>
> When code is being modified to add a feature or fix a bug, a<br>
> programmer might want to introduce a new variable for a temporary<br>
> result. In a long function body, this risks introducing a new bug.<br>
> Consider the following:<br>
> <br>
> g(Stuff) -><br>
> ...<br>
> Thing = case ... of<br>
> {a, T} -> T;<br>
> _ -> 0<br>
> end,<br>
> ...<br>
> {ok, [Thing|Stuff]}.<br>
> <br>
> Here, `T` is a new variable, clearly intended as just a temporary and<br>
> local variable for extracting the second element of the tuple. But<br>
> suppose that someone adds a binding of the name `T` further up in the<br>
> function body, without noticing that the name is already in use:<br>
> <br>
> g(Stuff) -><br>
> ...<br>
> T = q(Stuff) + 1,<br>
> io:format("~p", [p(T)]),<br>
> ...<br>
> Thing = case ... of<br>
> {a, T} -> T;<br>
> _ -> 0<br>
> end,<br>
> ...<br>
> {ok, [Thing|Stuff]}.<br>
> <br>
> Now the first clause of the case switch will only match if the second<br>
> element of the tuple has the exact same value as the previously<br>
> defined `T`. Again, the compiler quietly accepts this change, while<br>
> if it had been instructed to warn about all non-annotated uses of<br>
> already bound variables in patterns, this mistake would have been<br>
> detected.<br>
> <br>
> <br>
> Shadowing in Funs and Comprehensions<br>
> ------------------------------------<br>
> <br>
> In funs and comprehensions, pinning also lets us do things that<br>
> otherwise requires additional temporary variables. Consider the<br>
> following code:<br>
> <br>
> f(X, Y) -><br>
> F = fun ({a, Y}) -> {ok, Y};<br>
> (_) -> error<br>
> end,<br>
> F(X).<br>
> <br>
> Since the `Y` in the clause head of the fun is a new shadowing<br>
> instance, the pattern will match any value in that position. To match<br>
> only the value passed as `Y` to `f`, a clause guard must be added, and<br>
> a temporary variable be used to access the outer `Y`:<br>
> <br>
> f(X, Y) -><br>
> OuterY = Y,<br>
> F = fun ({a, Y}) when Y =:= OuterY -> {ok, Y};<br>
> (_) -> error<br>
> end,<br>
> F(X).<br>
> <br>
> We could instead rename the inner use of `Y` to avoid shadowing, but<br>
> the equality test must still be written as an explicit guard:<br>
> <br>
> f(X, Y) -><br>
> F = fun ({a, Z}) when Z =:= Y -> {ok, Y};<br>
> (_) -> error<br>
> end,<br>
> F(X).<br>
> <br>
> With the help of the pinning operator, such things are no longer a<br>
> concern, and we can simply write:<br>
> <br>
> f(X, Y) -><br>
> F = fun ({a, ^Y}) -> {ok, Y};<br>
> (_) -> error<br>
> end,<br>
> F(X).<br>
> <br>
> Furthermore, in the odd case that the pattern would both need to<br>
> access the surrounding definition of `Y` as well as introduce a new<br>
> shadowing binding, this can be easily written using pinning:<br>
> <br>
> f(X, Y) -><br>
> F = fun ({a, ^Y, Y}) -> {ok, Y};<br>
> (_) -> error<br>
> end,<br>
> F(X).<br>
> <br>
> but in current Erlang, two separate temporary variables would be<br>
> required:<br>
> <br>
> f(X, Y) -><br>
> OuterY = Y,<br>
> F = fun ({a, Temp, Y}) when Temp =:= OuterY -> {ok, Y};<br>
> (_) -> error<br>
> end,<br>
> F(X).<br>
> <br>
> As explained before, the same goes for patterns in generators of<br>
> comprehensions.<br>
> <br>
> <br>
> <br>
> Backwards Compatibility<br>
> =======================<br>
> <br>
> The addition of a new and previously unused operator `^` does not<br>
> affect the meaning of existing code, and the compiler will not emit<br>
> any new warnings or errors for existing code, unless explicitly<br>
> enabled with `warn_unpinned_vars`. This change is therefore fully<br>
> backwards compatible.<br>
> <br>
> <br>
> <br>
> Implementation<br>
> ==============<br>
> <br>
> The implementation can be found in [PR #2951][pr].<br>
> <br>
> <br>
> <br>
> Copyright<br>
> =========<br>
> <br>
> This document has been placed in the public domain.<br>
> <br>
> <br>
> [Elixir doc]: <a href="https://elixir-lang.org/getting-started/pattern-matching.html#the-pin-operator" rel="noreferrer" target="_blank">https://elixir-lang.org/getting-started/pattern-matching.html#the-pin-operator</a><br>
> "Elixir pattern matching - the pin operator"<br>
> <br>
> [pr]: <a href="https://github.com/erlang/otp/pull/2951" rel="noreferrer" target="_blank">https://github.com/erlang/otp/pull/2951</a><br>
> "#2951: Add a new operator ^ for pinning of pattern variables"<br>
> <br>
> <br>
> <br>
> [EmacsVar]: <> "Local Variables:"<br>
> [EmacsVar]: <> "mode: indented-text"<br>
> [EmacsVar]: <> "indent-tabs-mode: nil"<br>
> [EmacsVar]: <> "sentence-end-double-space: t"<br>
> [EmacsVar]: <> "fill-column: 70"<br>
> [EmacsVar]: <> "coding: utf-8"<br>
> [EmacsVar]: <> "End:"<br>
> [VimVar]: <> " vim: set fileencoding=utf-8 expandtab shiftwidth=4 softtabstop=4: "<br>
<br>
<br>
-- <br>
<br>
/ Raimo Niskanen, Erlang/OTP, Ericsson AB<br>
</blockquote></div></div></div>