New EEP draft: Pinning operator ^ in patterns

[zxq9]

On 2021/01/22 18:09, Raimo Niskanen wrote:
> On Fri, Jan 22, 2021 at 02:28:35AM +0900, zxq9 wrote:
>> On 2021/01/22 1:43, Tristan Sloughter wrote:
>>> I've tried to just say my piece and leave it at that (summary: not a fan
>>> but would be nice to have a way to match in fun heads/list
>>> comprehensions where variables are shadowed) but have to say that after
>>> seeing these examples I'm starting to lean towards agreeing with Richard.
>>
>> I'm the opposite, but it probably doesn't matter.
> 
> Why should it not matter?
> 
> What might matter would be stating good arguments for one's reasoning.
> 
>> Someone has an immaculate plan.
> 
> Instead of such statements.

HAHAHAHHAHAAHAHAHAHAHAHAAHAA!!!
[deep breath]
HAAAAAAAAAAAAAAAAAAAAAAAHAHAHAHAHHAHAHAHAHAHA!

Here is how this goes.
You say "Make an argument"
I do. Many do.
You say "Well, I don't feel that addresses X"
We address X directly.
"Well, that's not what I meant so derpy-doo let's just go with the plan!"

ffs...

 > You are attempting the Trump argumentation line:
 >     Repeat a lie until it is accepted as true.
 > I hate that.  Please stop doing that!

Bringing Trump up is just perfect.
Bravo.

Incidentally, let me define the Woke technique:
1. Introduce a fringe problem almost nobody feels they have that only 
presents in a corner case and change core principles everyone else has 
followed based on it.
2. Have extended and very serious discussion about THE PROBLEM to 
encourage everyone to overthink it and bikeshed endlessly over it. This 
is a good technique for getting THE PROBLEM on everyone's mind so they 
are aware when it is mentioned it is indeed a Very Big Problem.
3. If any contrary argument is presented no-true-scotsman the point 
presented as not "really" addressing the point you are asking for 
comment on.
4. Convinced you've made enough noise, regardless of feedback or 
suggestions, just go through with whatever your plan originally was 
because the noise was really about signaling intent not entertaining 
discussion and meaningful debate.

Stunning. And. Brave.

Ah, also, don't forget to keep lists and cancel dissenters at some point 
in the future. "Unity!" amirite?

That's how you destroy a community over time.
But whatever, this appears to be the year to destroy all old things that 
work well.

Can't wait to get off this crazy train.

Why is using Elixir not good enough? It already exists.
Why not discuss eliminating shadowing entirely? Is there some reason 
this suggestion has not been addressed at all? It is a curious omission 
given that it has been brought up multiple times.

Let's say I want to forward a message to all clients, skipping the 
origin of the message. For example does this not make quite sense?

f(Message, Origin, Clients) ->
   ForwardTo =
     fun
       (Origin) -> ok;
       (Client) -> Client ! {msg, Origin, Message}
     end,
   lists:foreach(ForwardTo, Clients).

Why must we use a guard here instead? OH THE PINNING OPERATOR!
No.
I mean, why is it allowed that Origin means one thing in just the 
lambda's head but another in the body of the lambda if otherwise not 
appearing in its head? We are able to close over values.

The design decision to allow shadowing in this one silly case was a 
mistake, a minor blemish on the language. We have a warning about it 
because it is a blemish. But the proposal to "fix" it is to introduce an 
even worse blemish -- great, now we have two blemishes and no fixes.

That's not what "fix" means.

Your question #1 in some previous message, "would this change make 
Erlang a better language?" was answered directly: No. It will not. It 
will make it more complex and confusing to explain to beginners and 
introduce a feature with a name that is going to be very hard for 
newcomers (and oldcomers not following the list and reading every line 
of the release notes) to search for when they first encounter this.

A fix would literally be to fix the actual root problem: the ability to 
shadow on literally the same line where you might close over a value 
from the surrounding scope. I would point out that creating closures is 
the main utility of anonymous functions in Erlang, and it would be a 
benefit to make the definition of those lambdas consistent with every 
other area of the language. No need for the "intention to be clear" -- 
just make the rule consistent everywhere and you have no confusion about 
intention. We don't have to "pin" values in case, if, matching for 
assertion, double assignment of the same value to check if it is the 
same value in a normal function head, etc.

Either
1. Leave it the way it is now because everyone knows it already.
2. Move toward eliminating shadowing completely.

In all cases:
- Encourage shorter functions.
- Stick to core principles.
- Remember that just because bad code exists out there and horrible code 
can be written in any language does NOT mean that you should enable the 
casual creation of trash-tier code.
- If you are maintaining a codebase with silly problems FIX THAT CODE.

-Craig