On Fri, Jan 22, 2021 at 08:57:29PM +0900, zxq9 wrote:
> On 2021/01/22 18:09, Raimo Niskanen wrote:
> > On Fri, Jan 22, 2021 at 02:28:35AM +0900, zxq9 wrote:
:
> 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.
Apparently I still did not think it addressed X.
> "Well, that's not what I meant so derpy-doo let's just go with the plan!"
"go on with the plan" is an incorrect suggestion that there is a 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.
Sorry about that! It was inappropriate.
But you repeatedly claimed that what you write would not matter because
someone(s) have a hidden agenda. There is no agenda I am aware of, and
repeatedly claiming that will undermine the faith in the EEP process.
And yes, there is an EEP process, it is stated in EEP 1, a bit outdated,
but nevertheless.
>
> Incidentally, let me define the Woke technique:
> 1. Introduce a fringe problem almost nobody feels they have that only
I do not think it is a fringe problem.
> presents in a corner case and change core principles everyone else has
I do not think it changes core principles.
> followed based on it.
:
> Why is using Elixir not good enough? It already exists.
I do not like Elixir.
> 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.
It has been talked about, and I am for!
Oddly enough ;-) I think the pinning operator would help when removing
shadowing:
foo(X) ->
F = fun (A, ^X) ->
{A, X}
end,
instead of
foo(X) ->
F = fun (A, X1) when X1 =:= X ->
{A, X1}
end,
I think the first is neater, since that is how you can write it in a case.
The X is the X everywhere. Without the pinning operator one can easlily
miss that the ^X is a match.
Just removing shadowing would make it like matching in case today.
That would also make the language be more uniform.
But I think would be a source of error since it is hard to tell what
is a match and what is a bind. Just like matching in case patterns today.
>
> 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.
Smoke screen. It is primarily not this problem that is targeted.
>
> 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
Those are not answers. Those are opinions.
That was not a question. It was a discussion subject.
> 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.
Those are assumptions.
>
> 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
And I say that the root problem is the automatic binding in a pattern.
Under that assumption would removing shadowing in fun() heads increase the
root problem.
> 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" --
Some think that consistency in this case is that there should be no way a
variable has a different value in a fun() than outside it. Not all share
your view of consistency here.
That Erlang does not have a possibility for proper variable scoping
is a problem, though. At least for writing macros.
> 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
There is no confusion about intention.
The purpose is to clarify the intention.
> 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.
Functions should have their proper size. Do not create lots of small
functions for the sake of principles.
> - Stick to core principles.
It seems which principles are core principles varies.
> - 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.
I agree. Was that ever suggested?
> - If you are maintaining a codebase with silly problems FIX THAT CODE.
Easy to say. Harder to do. Often no business case for that.
>
> -Craig
Best regards
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB