Re: [Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055

[Leonard Boyce]

I'm copying the Erlang Questions ML with this post since there was
significant and heated discussion regarding this EEP and not all ML
subscribers have joined the forum.

On Wed, Apr 20, 2022 at 10:20 PM Bryan Paxton via Erlang Forums
<nor...@erlangforums.com> wrote:
>
> starbelly EEF Board
> April 21
>
> EEP-0055 (https://github.com/erlang/eep/blob/master/eeps/eep-0055.md) was submitted on
> 21-Dec-2020.
>
> An accompanying implementation (https://github.com/erlang/otp/pull/2951) was submitted in which a lot of conversation ensued.
>
> It was decided that the EEP would not be set for inclusion in OTP-24, per the time table at that juncture and that it would be revisited prior to OTP-25. OTP-25 is now at a point where this is not possible.
>
> That said, I wanted to start a topic here about the EEP and gun for inclusion in OTP-26.
>
> I would point to @kennethL’s last comment (https://github.com/erlang/otp/pull/2951#issuecomment-770878570) on the PR as a starting point for discussion.
>
> I suppose my overarching question here is : Is this still on the table? And if so, what are the road blocks? Kenneth pointed out some possible roadblacks that needed investigation, but it’s not clear to me what happened after that.
>
> Of course, since I’m raising this topic, I’m obviously in favor of the operator I’d also be happy to work to drive it forward.
>
> ________________________________
>
> Visit Topic or reply to this email to respond.
>
> You are receiving this because you enabled mailing list mode.
>
> To unsubscribe from these emails, click here.
>
>

[zxq9]

From the EEP, which is about "pinning operators" (will the nonsense
cease?):
> In Erlang, they would be optional

So why would you even want this? The entire idea is stupid, *implies* a
break with the basic rules already built into the language, and appears
to be nothing more than a way to roadmap the destruction of Erlang over
time with gee-whiz glyphy syntax of the sort which Erlang has been thus
far generally free.

That's a big "NO" from me on this EEP, but I imagine anyone could have
already guessed that. Thanks for the heads up. I don't expect sanity to
prevail over time -- it is just the trend of the times -- but it was
interesting to at least see this mentioned to those of us still
subscribed to the bad dirty old ML.

-Craig

[Eric Pailleau]

Yes, this 'pinning operator' will just pin erlang in the extinct species museum.

Envoyé depuis mon mobile

---- zxq9 a écrit ----

[Stanislav Ledenev]

Agree. Unfortunately some of the latest EEPs (IMHO) are a sign of leaving Erlang's way 

of doing stuff in the style of "we have a problem let's find a solution" to a way of modern 

fancy languages of "let's invent a problem and find a solution (which becomes another problem to solve)".

And furthermore in this particular EEP there's this thing I hate more than anything else - turning language X to language Y. 

Quote - "This is known as "pinning" in Elixir - see the Elixir documentation." 

If you like Elixir do your job with Elixir. Why spoil Erlang? 

Especially when, quote - "In current Erlang, this behaviour is what happens automatically...".

All this nonsense with adding this to the language will "make programs more readable". 

In all history adding more language constructions never improved

 anything in any language. Look at C++, C++ 20 and C++ 11 are totally different languages!

Unfortunately, the more I code (20+ years), the more I see programming 

languages tombstones with the epitaph "I've been improved and died".

пн, 25 апр. 2022 г. в 08:29, zxq9 <zx...@zxq9.com>:

[Michael Malter]

I said it for years. Elixir is cutting the branch it is sitting on.

Oh well, we will be fine for quite a few years.

I haven't read the whole thing, it is quite difficult to digest but I am not sure anyone mentioned that sigils are hard to read. It's bad in ruby, horrible in perl. I am not sure why we are taking ideas from these languages. I mean, I actually enjoy writing ruby but just fail to see where it stands in a prology context.

Little funny story on the side. I go to a local erlang meetup, the topic of the day is "Discovering erlang" or something similar. An organizer litteraly shouted on me just for mentionning erlang. The whole thing revolved around selling elixir products. I'll let you imagine the atmosphere in the room, full of begginers. One (courageous ? ) guy left on the spot.

 

We all wished the coexistence would be peaceful and productive. It certainly was for the most part. But let's face it we are more and more dealing with monkey crusaders. Consultants also. If I have an economic incentive to tell you that making a pabx in fortran is great, I'll just tell you that. 

This proposal reeks of "Erlang does not look like what I am used to, so let's make it user friendly".

[Sean Hinde]

Big no from me as well. I thought we had done this discussion to death.

Yes, Erlang has a small unfortunate issue. But a face with a wart on its chin is not improved by a much bigger one on the end of its nose!

/Sean

[Nicolas Martyanoff]

Stanislav Ledenev <s.le...@gmail.com> writes:

> In all history adding more language constructions never improved
> anything in any language. Look at C++, C++ 20 and C++ 11 are totally
> different languages!

I cannot agree more.

The saddest part of this whole thing is that there are obvious areas of
improvements:

- Improve dialyzer to work as other modern type annotation systems (i.e.
treat type annotations as the truth and signal errors when the code
does not satisfy them), and make its output readable.

- Introduce a standard build/package system with dependency support,
similar to go mod (for all its faults, it works).

- Add a way to build self-contained single executables (again, something
Go.

- Retire the entire string-as-list paradigm, use binaries by default
(the one good thing about Elixir), and at last make everything UTF-8
by default.

- Clean and modernize the standard library.

And the list could go on for pages, without having to destroy the basic
concepts of the language.

--
Nicolas Martyanoff
http://snowsyn.net
kha...@gmail.com

[Р.С. Алиев]

25.04.2022 11:42, Nicolas Martyanoff пишет:

> And the list could go on for pages, without having to destroy the basic
> concepts of the language.

Somehow my (sad) feeling is the idea is exactly in destroying the Erlang
as we know it. "No matter how hard we try, we cannot make Elixir more
preferable -- at least let us make Erlang *less* preferable."


--
С уважением,
Р.С. Алиев

[Karl Velicka]

Isn't that being at least a bit exaggerated/hyperbolic? Erlang has fairly glyphy <<"binaries">>, $c $h $a $r $s are also not entirely glyph-free, and neither are ?MACROS. Or the "send" operator (!), though it's not often used in production code in my experience.

While I'm not massively for this particular EEP (I'd describe my position as ambivalent - I'd use it if it made it in, but I'll lose zero sleep if it doesn't), it feels like some people in this list (and this is most definitely not aimed at Craig in particular!) are laying the hyperbole on thick. A few key points appear to be "new == bad", "comes from elixir == bad", "look at C++ and how terrible that is going". So, I'd like to raise some questions in response:

* Do people here genuinely feel that Erlang is in its global optimum state right now and there are no positive improvements that can be made?

* Do people here genuinely believe that Elixir is strictly a bad thing, no positive things can come of it, and any ideas that in some way originate from Elixir is some kind of plague?

* Lastly, there's a theme of taking potshots at C++. While it is true that its evolution brought some bad things along with the good, I've not heard a single C++ developer wishing that they could move their codebase(s) back to an older C++ standard, which actually happens to be entirely feasible in C++ ecosystem (some people/orgs run some _very_ old codebases, and as a result ancient codebases are supported by newest versions of compilers). So, how bad is the situation in "modern" C++ land really..? (this last question is more rhetoric - I do not with to start a lengthy discussion about merits of C++'s new additions in an Erlang mailing list)

There's also some suggestions of how Erlang _should_ evolve. Those include things that I also consider good ideas, but in some cases making them a reality can be tricky because one has to work out a  backwards compatibility strategy, provide some reference implementation etc. Criticising such work produced by others is on the other hand relatively easy. So I ask the proposers -  how are _you_ contributing to a more "Erlang-y"  future of the language? where are your EEPs? It's clear that some people in the community use Erlang extensively enough to face some issues with the language, and they're trying to make suggestions on how these might be improved. What we get from the mailing list community is a bunch of claims about how the proposers' problems are not real problems and/or their solutions are literally killing the language. So, my last question is - doesn't this kind of attitude have some elements of cutting the branch we (as the Erlang community) are sitting on..?

I hope my questions didn't offend anyone (and particularly people whose points I referenced in my mail) - I've been a reader of the mailing list for many years and learned a lot from the regular posters here. However, there's been a few "incidents" over the years where some seemingly small things got blown completely out of proportion, and I think the community would be better off if its members firstly assumed overall positive intent (even though it might have downsides for some individual users), and took a few deep breaths before hitting "send", particularly in cases where typing up your response was a blood-pressure-raising activity.

I wish everyone all the best, and I hope  that this (and future) discussions could get a tiny bit less emotionally charged.

Karl

[Nicolas Martyanoff]

Łukasz Niemier <luk...@niemier.pl> writes:

>> - Improve dialyzer to work as other modern type annotation systems (i.e.
>> treat type annotations as the truth and signal errors when the code
>> does not satisfy them), and make its output readable.
>

> There is work on Gradualizer which seems like faster and better
> Dialyzer alternative.
When I tried it, it was interesting but far from production readiness.
It simply was not ready for maps (yet another problem, there should a
proper record system which is *not* based on preprocessor tricks).

This kind of tool should be part of Erlang/OTP and maintained by Ericsson.

>> - Introduce a standard build/package system with dependency support,
>> similar to go mod (for all its faults, it works).
>

> There is already Hex.pm that does exactly that. And IIRC there were plans to make
> Rebar3 part of the OTP.
Hex.pm has nothing to do with associating packages to my project with
the right version. It is a third party website forcing everyone in a
global namespace.

Rebar3 is clearly not part of OTP, it is still a third party tool which
has to work around OTP (see the numerous hacks in relx and rebar3).

>> - Add a way to build self-contained single executables (again, something
>> Go.
>

> That is pretty hard to do, as Erlang requires some external libraries in most cases
> (OpenSSL for example) and it is hard to make them in such "single binary". There are
> tools that make it a little bit easier though (these create self-extracting archives).
> This however is still not super easy, as the VM need to be compiled
> for target machine.
Of course it is hard. But this is actually useful. Solving the NIF
situation, i.e. having a way to ship an escript with NIFs, would be a
good start.

>> And the list could go on for pages, without having to destroy the basic
>> concepts of the language.
>

> I do not understand how this proposal destroys "basic concept of the language".
> It is meant only to explicitly mark situations when you want to pattern match
> on existing binding to avoid some headaches and to allow some
> readability improvements.
There is no point in debating that point, it is obvious that the
proposal divides the entire community.

[Nicolas Martyanoff]

I would not go that far. I have no information suggesting that Ericsson
is interested in Elixir in any way.

And I am almost convinced they do not care about Erlang anymore. These
new shiny 5G platforms are not written in Erlang (if I am wrong, please
convince Ericsson to release the required HTTP2 and JSON
implementations).

[Stanislav Ledenev]

I'll speak for myself.

>> * Do people here genuinely feel that Erlang is in its global optimum
>> state right now and there are no positive improvements that can be
>> made?

I think that Erlang as a language is quite close to its optimal
state: quite strict and simple (though powerful) syntax,
convenient modules concept, powerful OTP e.t.c.
Anything that I'll ever need can be implemented through libraries.
And the only language change which I'll be glad for is a native utf-8 string support.
Of course there are few libraries but it brings unneeded variations of implementations.

>> * Do people here genuinely believe that Elixir is strictly a bad thing,
>> no positive things can come of it, and any ideas that in some way 

>> originate from Elixir is some kind of plague?

I don't like Elixir because it is a category of syntactic sugar language which I
don't think is any good. But it is as it is and let it be.
What I hate most and this is very important is those changes to Erlang
rationalized by examples of the other language.
It is a road to hell.
For example, imagine what would happen if some ideas were brought to the Erlang
if we took some stuff from LFE(Lisp flavoured Erlang) to the core?

>> * Lastly, there's a theme of taking potshots at C++. While it is true
>> that its evolution brought some bad things along with the good, I've
>> not heard a single C++ developer wishing that they could move
>> their codebase(s) back to an older C++ standard, which actually
>> happens to be entirely feasible in C++ ecosystem (some people/orgs run some _very_ old codebases, and as a result
>> ancient codebases are supported by newest versions of compilers).
>> So, how bad is the situation in "modern" C++ land really..?
>> (this last question is more rhetoric - I do not with to start a lengthy
>> discussion about merits of C++'s new additions in an Erlang mailing list)

I strongly recommend to read this little paper of Bjarne Stroustrup
https://www.stroustrup.com/P0977-remember-the-vasa.pdf

excerpt: "...so my reading of the Vasa story is: Work hard on a solid foundation, learn from
experience, and don’t scrimp on the testing.

The foundation begun in C++11 is not yet complete, and C++17 did little to make our
foundation more solid, regular, and complete. Instead, it added significant surface complexity
and increased the number of features people need to learn. C++ could crumble under the
weight of these – mostly not quite fully-baked – proposals. We should not spend most of our time
creating increasingly complicated facilities for experts, such as ourselves."

I mention C++ as an example of weird language evolution (?). C++ is evolving but
in a strange way. It's always becoming more and more complex, not the opposite.
If anyone writes C++ as it is he/she must write more and more code to solve
same old problems. As one of the examples - "Rule of three" became "Rule of five".

At the same time there were so many languages which promoted themself as a "C++ killer" but C++ is still alive.
The problem with C++ - it kills itself. C++ is slowly dying. I can hardly
see any young software developers who wish to learn C++. They must learn so many
weird concepts to get so little. Even memory management with C is much easier
they can understand than this crap "rvalue"/"lvalue" stuff with copy, copy-assign, move etc.

I'd be more sad if this happens with Erlang.

пн, 25 апр. 2022 г. в 12:16, Karl Velicka <karolis...@gmail.com>:

[Nicolas Martyanoff]

Łukasz Niemier <luk...@niemier.pl> writes:

> OTP and Erlang are open source projects. Have you tries to improve state
> of Dialyzer on your own? Or you are trying to force someone else to do that
> for you? Ericsson was recently looking for people to work on Erlang, have
> you tried to apply and work on that stuff for yourself?

Personal attacks are not welcome. Nobody here owes free work to anyone,
we are just discussing about Erlang.

Ericsson if free to ignore any comment. People are free not to use
Erlang. Nothing new here.

>> There is no point in debating that point, it is obvious that the
>> proposal divides the entire community.
>

> But I do not understand why it divides the community so much.

And I do not understand those who support this EEP. This kind of
communication issue is usually what fragments communities.

[zxq9]

On 2022/04/25 18:16, Karl Velicka wrote:
> Isn't that being at least a bit exaggerated/hyperbolic? Erlang has
> fairly glyphy <<"binaries">>, $c $h $a $r $s are also not entirely
> glyph-free, and neither are ?MACROS. Or the "send" operator (!), though
> it's not often used in production code in my experience.

Escapes tend to require at least one reserved glyph. This is the tyranny
of ASCII creeping through. The point is to have as little of this as
possible and Erlang buys us quite a lot with the handful of instances
of glyph escapes that it does have. Adding an operator that is purely
optional but implies a semantic change is the opposite of "improvement"
and makes understanding code less simple.

> While I'm not massively for this particular EEP (I'd describe my
> position as ambivalent - I'd use it if it made it in, but I'll lose zero
> sleep if it doesn't), it feels like some people in this list (and this
> is most definitely not aimed at Craig in particular!) are laying the
> hyperbole on thick. A few key points appear to be "new == bad", "comes
> from elixir == bad", "look at C++ and how terrible that is going". So,
> I'd like to raise some questions in response:

It's ok, I'm a popular target. :-)

> * Do people here genuinely feel that Erlang is in its global optimum
> state right now and there are no positive improvements that can be made?

It is remarkably close to an optimum, yes. As a language, anyway.
Try designing a language, then stepping away from it for a year, then
come back and take a close look at it as an outsider.
It will very likely bother you.

Another language that is *very close* to optimum is Sophia.
Not perfect, but remarkably close to optimum, especially considering
its domain (smart contracts). I was so impressed with it that I would
consider making a "Sophia Flavored Erlang" if I happened to have
Elon Musk money. But I don't, so that's never going to happen.

Guile2 is also remarkably close to optimum, and similarly un-cool for
whatever reason. I don't pick what genpop finds cool and trendy, but I
can pick what I am going to use about 90% of the time, and Guile is
a really remarkable little language and runtime.

In Erlang probably the major change I would make is actually related to
shadowing and is something we even have a compiler warning about but is
not enforced: make *matches* in lambda argument lists occur rather than
*shadowing*. That is, don't add a pinning operator, just unify the
existing semantics of the language. Done. Simple. Now write code, not
ML posts about fever dream additions so Erlang can look more like
something else.

In the stdlib I might make a stdlib2 that standardizes things like
argument order and similar nitpicks, but this is really splitting
hairs and is *not* the language itself -- and can 100% be (and
should be IMO) an external project, so isn't even a language change.

I could say similar things about the type system and improvements
that could be made with a -pure declaration -- but this is also not
the core language itself.

Anyway, these amount to really minor nitpicks. Adding the pinning
operator would add *another* and much stronger area I would want to
simplify and clean up (a campaign to remove the pinning operator if
one existed would be higher in priority than the things I mentioned
above), so I'd rather not see it added in the first place. It would
be "let's make module namespaces into objects!" all over again.

Any larger and more disruptive change to Erlang would really be a
call for a different language, not a reasonable change to Erlang
itself.

> * Do people here genuinely believe that Elixir is strictly a bad thing,
> no positive things can come of it, and any ideas that in some way
> originate from Elixir is some kind of plague?

No. I'm not a fan of Elixir, but if people like it, fine, use it. The
reasons I don't like it are why I like Erlang more, though, and I don't
want to see Erlang become Elixir by increments. That is the opposite of
having a meaningful diversity of available languages to drive the
runtime.

People who like Elixir use Elixir.
People who like Erlang use Erlang.
People who like LFE use LFE.
This is fine.

I really, really wish it were easier to support all of the BEAM
languages as purely peer languages (because then I could support
all of them in a single project under a single tooling umbrella)
but they aren't so whatever.

> * Lastly, there's a theme of taking potshots at C++. While it is true
> that its evolution brought some bad things along with the good, I've not
> heard a single C++ developer wishing that they could move their
> codebase(s) back to an older C++ standard, which actually happens to be
> entirely feasible in C++ ecosystem (some people/orgs run some _very_ old
> codebases, and as a result ancient codebases are supported by newest
> versions of compilers). So, how bad is the situation in "modern" C++
> land really..?

I know C++ developers (especially in client-side game development) who
wish they could have kept C++11 forever, and some even previous versions
and quite a few who wish they could just stick with C *or* move to
something completely different than a C-based language entirely.

It is fascinating that reading and thinking carefully about the C++ FQA
is a better cognitive exercise than reading through the C++ FAQ.

> So I ask the proposers -  how are _you_ contributing to a more
> "Erlang-y"  future of the language? where are your EEPs? It's clear that
> some people in the community use Erlang extensively enough to face some
> issues with the language, and they're trying to make suggestions on how
> these might be improved. What we get from the mailing list community is
> a bunch of claims about how the proposers' problems are not real
> problems and/or their solutions are literally killing the language. So,
> my last question is - doesn't this kind of attitude have some elements
> of cutting the branch we (as the Erlang community) are sitting on..?

I've given up on the part of the community that deliberately sought to
divide the community into people who follow the woke cult religious
dogma of ESG and DIE and enforce that division with a CoC. I have no
expectation that Erlang will hold together. This will be very sad, but
will not impair my ability to write useful software in whatever language
sucks the least at a given moment. Currently Erlang sucks the least for
most of the things I write, but that situation could change and likely
will as more garbage gets pumped into it.

My attitude about this is by no means unique, I am just in a position
professionally where I can actually say what I think out loud because
nobody can fire me for my beliefs -- a situation almost nobody in
the West enjoys at this point.

In fact, on this point, a member of my outcast community of math
and programming heretics wrote a few essays touching on this phenomenon
just the other day:

"Preference falsification:
Common sense in the back, compliance in the front"
https://zxq9.com/archives/2107

"Moral insecurity: why I’m racist"
https://zxq9.com/archives/2410

They are interesting essays and apply to the social problems that
are infecting and slowly (sometimes quickly) destroying almost every
open source community now (not to mention undermining faith in
public institutions and academia at a remarkable pace).

Anyway, the graybeard arguments against such changes as including
new stuff in the *language* that cannot be easily changed back rather
than focusing more effort on the runtime and libraries and tooling
is mostly in the spirit of delaying the eventual destruction of
Erlang's near-golden balance as a simple, small language.

Language design is *really* hard to get right and *very* easy to
screw up. There is a reason most of the old Pythonistas still
support, patch and write new code in 2.7 -- and also a reason that
Guido finally threw his hands up and quit in despair.

As for how are any of us trying to improve things... I've taken the
time to write a complete dynamic template/package/serve/build/launch
toolset for Erlang in Erlang, but just around the time I thought it
might be good to promote it people basically seem to have lost their
minds in ways that have nothing to do with the tech itself, so I'd
just rather not be bothered dealing with people who make a hobby of
taking indirect offense on behalf of people who themselves fail to
be sufficiently offended by whatever today's outrage is supposed to
be.

Why did I write tooling? Because that's the problem Erlang has.

Tooling.

Releases aren't the way and harsh responsibilities about dependency
management have to be assigned if you want a system where you can
simply type (as a user) `zx run [program name]` from anywhere that
has a network connection and have everything pull, build and run
in a sane way (that is, bring the ease of use of npm to Erlang but
without the insanity of npm dependency resolution).

Anyway, the main problem Erlang has is tooling and platform issues,
not language issues (and by "platform issues" I mean that I've already
solved the "first invocation means to pull and build" problem in a
cross-platform way, to the point you can write GUI apps that "just
work" anywhere, but still can't play sound or access audio/video
libs in a sane way that works cross platform -- if I could I would
probably eventually write game libs and VOIP clients in Erlang too).

The second problem Erlang has is the divided nature of the community,
which is why I tend to hang out with a handful of misfits, some of
whom must keep themselves anonymous for fear of reprisal for speaking
their mind. That's just how things are for now. Much like a stack of
other, similar situations in the world today, the problems are going
to get a whole lot worse before it gets better.

It is worth mentioning that there are no technical solutions for
social problems. Quite a lot of modern trouble exists due to a general
failure to understand how deeply this is true.

I hope everyone is having as pleasant a northern springtime as possible.

-Craig

[Loïc Hoguin]

Thanks for bringing this to our attention.

I do not see what has changed in the EEP to warrant taking another look
at it. In particular, it still is a specialized use case of annotations
which I would be fine adding to the language as long as they're generalized.

This

f(X, Y) ->
case X of
{a, ^Y} -> {ok, Y};
_ -> error
end.

does nothing to me. The ^ is rare enough that you will scratch your head
to remember what it's about and what the rules are, especially in more
involved scenarios such as

f(X, Y) ->
F = fun ({a, ^Y, Y}) -> {ok, Y};
(_) -> error
end,
F(X).

The description of this snippet is also not clear: "In this case, the
pinned field refers to the value of the function function parameter, but
there is also a new shadowing binding of Y to the third field of the
tuple. The use in the fun clause body now refers to the shadowing
instance." - what's the point of allowing this monstrosity? That's just
being too smart for your own good.

If annotations are generalized we could instead have

f(X, Y) ->
case X of
{a, ^match Y} -> {ok, Y};
_ -> error
end.

and we could use them for other things such as

^remote Pid ! Msg

which can then be used by other tools to help better understand the
code. I don't think we would end up with too many annotations ultimately
so using a single word for this is probably enough. No opinion on the ^
character.

Since this is annotations, this ought to be optional, although of course
teams may decide to force the use of ^match in their own projects along
with the related compiler warnings.

Cheers,

--
Loïc Hoguin
https://ninenines.eu

[Stanislav Ledenev]

One question - why? Just because we can?

Erlang is doomed, Sorry Joe, we f**d things up.

пн, 25 апр. 2022 г. в 16:42, Loïc Hoguin <es...@ninenines.eu>:

[Austin Ziegler]

On Mon, Apr 25, 2022 at 10:58 AM Stanislav Ledenev <s.le...@gmail.com> wrote:

One question - why? Just because we can?

Erlang is doomed, Sorry Joe, we f**d things up.

 

I really can’t help but laugh at over the top reactions like this and those who can’t help but bash Elixir because they don’t like the syntax.

What if this syntax (or some other syntax) helps the compiler generate better (safer, faster, whatever) code? How would anyone know unless it gets tried? Why would anyone want to try it when they know that a certain vocal subset of the community are going to be pitching embarrassing fits over it?

If this is introduced in OTP 26, then stop upgrading. Seriously. Stay on OTP 25 or before. But seriously, stop acting like children about this and saying that things are fucked up (because they’re not; you just don’t like this because you don’t like it). The only real objection that I’ve seen that makes sense to me is from Loïc, which is that it might be better to enable annotations, even if the only annotation initially available is for pinning. (My personal feeling on the annotation concept is that `^pin Variable` doesn’t feel right to me, but maybe `^pin:Variable` or `^pin{Variable}` or `^{pin}Variable` or something else, although more sigil-y, would be clearer.

I mostly use Elixir, but often read Erlang codebases. On the Elixir core mailing list, there are frequent redirects to approach something as a possible PR to Erlang/OTP because it’s something that should benefit all BEAM languages.

Telemetry started as an Elixir library, but was quickly changed to a pure Erlang approach because it makes more sense to be something that all BEAM languages can use.

Elixir has — and I suspect both LFE and Gleam both have — enhanced the BEAM through wider exposure, code contributions, and other contributions. If you can’t argue a feature request like in this EEP on its merits (or lack thereof) without trying to bash Elixir, then maybe you don’t actually have an argument, but an emotional outburst, and should just discard your rant after writing it.

-a
--

Austin Ziegler • halos...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

[Loïc Hoguin]

Because it allows the code to be more explicit in a way that tools can
benefit from.

I do not personally think the ^match or the pin ^ is terribly useful,
but I think annotations in general very well COULD be. Note that I
assume that any additions of annotations to the language would be done
as an experimental feature first, which the Erlang compiler now should
be able to do better.

The Erlang language has had many experiments in the past, the most
infamous of which is tuple calls and its companion parameterized
modules. Them being added to the language as experimental does not mean
the feature is going to stay forever. It has to show proof in practice
that it is worthwhile.

About my ^remote example, we probably would have ^remote set when
matching the Pid originally, not in the send call, though:

#state{pid = ^remote Pid} = State,
Pid ! Msg

One could imagine enabling additional checks on this annotation, such as
validating that Pid is indeed a remote pid before sending messages to
this process. Coupled with a check that any other sends are local-only
and you end up with a project where it is easy to identify when messages
are sent over the distribution, which is HUGE for some projects.

This is similar to what the pin ^ operator is doing, except in a
different context. And that's why I would like to see a more general EEP
for annotations. I have no strong opinions on the syntax it should use.

On 25/04/2022 16:58, Stanislav Ledenev wrote:
> One question - why? Just because we can?
> Erlang is doomed, Sorry Joe, we f**d things up.
>
> пн, 25 апр. 2022 г. в 16:42, Loïc Hoguin <es...@ninenines.eu

> <mailto:es...@ninenines.eu>>:

>
> I do not see what has changed in the EEP to warrant taking another look
> at it. In particular, it still is a specialized use case of annotations
> which I would be fine adding to the language as long as they're
> generalized.
>

[k...@posteo.net]

I agree with this point. Less is more.

So far, Erlang managed to keep most of its core features orthogonal. Which helps adoption, since Erlang is a niche language with a well-defined problem domain in mind: it makes implementation of asynchronous and distributed systems easy and efficient. I'd had experience mentoring fresh graduates and juniors in Erlang, most of them were able to provide value to the product after three-four weeks of learning Erlang.

No one is going to bother learning a complex feature-rich language for just one domain. Currently Erlang is a nimble and efficient craftsman's tool, not a Swiss knife. Keep complexity for "general-purpose" languages that try to do everything, poorly.

[Austin Ziegler]

On Mon, Apr 25, 2022 at 11:27 AM Michael Malter <airl...@gmail.com> wrote:

Well I would rather let Joe rest in peace but the reference is probably helpful there.

Erlang is simple. I mean, that's how Joe saw it. He expressed it multiple times.

Simple is in the eye of the beholder. I would disagree with the assessment that Erlang is simple, but From a Certain Point of View, it is, sure. Is it simpler than Elixir? In some ways, yes. In other ways, no. If you’re trying to say that Erlang is a small language, then I’d mostly agree. So is Elixir, though. From certain points of view, Elixir is much easier to apprehend than Erlang, because Erlang is more sparse than Elixir. As a language.

That said, it took me a long time to understand `=:=` because it’s a complex, compound sigil (not used _that_ frequently) that I’ve never seen in any other language (and I know quite a few). To _me_, `^Value -> …` is clearer than `NewValue when Value =:= NewValue`. But that’s me.

 

Do you remember the time when that was the Java motto ? Look at Java now.

I never remember such a day. Granted, it got much worse after the introduction of J2EE and all that crap, but I never remember Java being "simple".

 

Is it so hard to understand what we are saying ? For once it's pretty clear and without many diverging opinions.

 

Except that there are numerous diverging opinions. They just tend to be drowned out by louder people who can’t seem to express their opposition in the simple, clear terms that you and Loïc have, and instead are making purely emotional expressions.

- it's not sufficiently useful to warrant another language features (you know, less is more)

- it's yet another sigil and we hate them. 

The former is arguable, and I’ve seen little in any of the threads about this EEP to suggest that this is the case. The latter is a matter of taste, but it’s also a legitimate concern. New sigils shouldn’t be added without good reason. I’ve seen such discussions in Elixir and Ruby language discussions, and sometimes a new sigil gets added (`&.` and `->()` in Ruby; I like the former, hate the latter, although I use it).

Not addressed in the original EEP (probably because it wasn’t originally considered) is whether expressing pinning might improve the compiler’s ability to generate better code. It’s been raised on the forum though, and it should be considered. If nothing else, it starts to indicate that there may be more use than simply avoiding guard clauses (which IMO is worthy in and of itself).

-a

[Stanislav Ledenev]

There were multiple arguments from a bunch of people.
The principle of the main one is "Render unto Caesar the things that are Caesar's, and unto God the things that are God's".

 If you like Elixir no one objects on this. Just leave Erlang alone.

But you just could not or don't want to listen. 

Perhaps because you are a fanboy not an engineer if you can't see such simple arguments. 

And It's pointless to argue to argue with fanboys.

пн, 25 апр. 2022 г. в 18:14, Austin Ziegler <halos...@gmail.com>:

[Loïc Hoguin]

On 25/04/2022 17:45, Austin Ziegler wrote:
> That said, it took me a *long* time to understand `=:=` because it’s a

> complex, compound sigil (not used _that_ frequently) that I’ve never
> seen in any other language (and I know quite a few). To _me_, `^Value ->
> …` is clearer than `NewValue when Value =:= NewValue`. But that’s me.

It's one of the flaws that I wish could be fixed. I use =:= everywhere
because it is more precise and it's the equivalent of == in many other
languages. The mix and matching of integers and floats is Erlang trying
to be too smart. Hopefully we can make == the same as =:= at some point
and get rid of =:= and =/=. Is there even that much code that relies on
Int == Float?

I have the same opinion on pretty much all uses of the "number" type, I
like to keep my integers away from my floats.

[Austin Ziegler]

No, Stansilav, I’m an engineer. I’ve shipped software in ~35 different languages, which means that I aim to get ship done.

If the only thing you can take away from my messages here is that I’m a "fanboy", then it is not my judgement in question.

I will reiterate that this EEP was filed by someone who primarily writes in Erlang and wishes to see it in Erlang because they believe it would be beneficial in one of several different ways.

The main objections that I have seen over the last two years on this have boiled down to:

- It makes Erlang look like Elixir

- It doesn’t add enough value

- It’s a new sigil, and new sigils are by definition bad

The first position, which is essentially what I have seen from you and several others, can be disregarded as emotional hyperbole. The second and third positions are worth discussing, but the level of emotion in the thread have resulted in little productive discussion on them.

The first and third positions have ultimately precluded substantial discussion on the second and have discouraged possible explorations to see if the second position is, in fact, true. As I understand it, the Erlang compiler has changed pretty substantially in OTP23, OTP24, and OTP25 (particularly with the introduction of the JIT in OTP24), which means that the introduction of a new sigil might permit the compiler to emit better (I’m being purposely vague here) code.

The OTP implementation team thinks that it’s interesting and while they may not pick it up, they might. If they do, I hope that they look at Loïc’s suggestion, because I am of the opinion that adding a sigil should be a rare event, but adding a sigil that allows for greater future extensibility just might be worth it, even at the cost of a little bit of verbosity.

In the end, you’re probably not going to listen and dismiss what I’ve said as fanboyism, but that doesn’t actually affect me.

-a

[Eric Pailleau]

Hi,

Sorry but the only common point between Erlang and Elixir should be BEAM.

That's all.

Following you point of view, we could write an EEP at Elixir to ask variables must be bound only once, like Erlang, because... (feel blanks).

Envoyé depuis mon mobile

---- Austin Ziegler a écrit ----

[Austin Ziegler]

On Mon, Apr 25, 2022 at 1:12 PM Eric Pailleau <eric.p...@wanadoo.fr> wrote:

Hi,

Sorry but the only common point between Erlang and Elixir should be BEAM.

That's all.

Following you point of view, we could write an EEP at Elixir to ask variables must be bound only once, like Erlang, because... (feel blanks).

Except that the EEP was not created by an Elixir developer, but an Erlang developer who found the concept useful. If I really felt that it would improve Elixir to have a "bind once only" rule change, I would absolutely suggest it with hopefully as much detail as was in this EEP that people have rejected for purely emotional reasons.

There are fairly frequent discussions on elixir-core about what would be good additions for Elixir. Sometimes they are accepted. Sometimes not. Sometimes the ideas are good, but felt not to be in the spirit of Elixir (a frequent request years ago would be auto-destructuring of maps; it has been rejected firmly, and there are rarely-used modules that can offer similar capabilities through Elixir’s macro capabilities). Sometimes the ideas are good, but considered to be better fits to propose to Erlang itself so that Elixir can build atop a stronger foundation.

What I haven’t seen in elixir-core is the emotional overreaction to an idea. It’s probably because elixir-core is small enough that the core developers and the language’s creator are still quite active in most discussions, which is not really true of the Erlang development core (especially since the move to the forum). Let me be clear, I’m not saying it’s because I think the Elixir community is better. I am impressed (mostly) with the Erlang community’s cohesiveness and ability to work together. I am disappointed that a good, well-written EEP is being dismissed for reasons that are more emotional than considered, and that there’s unnecessary sideswipes against other languages in the process.

I ultimately don’t care whether the EEP is adopted or not. If adopted as is, it offers some optimizations that may be usable by the compiler. If adopted with changes along Loïc’s suggestions, it offers room for future optimizations and extensibility without the use of further sigils. If adopted as the inverse meaning (as someone suggested, such that the pin marks a mutable instead of matching variable) the change will be more disruptive, but also equally good. If not adopted, Erlang will survive. But the discussion should be on the merits, not on comparisons.

-a

[Michael Malter]

Well I would rather let Joe rest in peace but the reference is probably helpful there.

Erlang is simple. I mean, that's how Joe saw it. He expressed it multiple times.

Do you remember the time when that was the Java motto ? Look at Java now.

Is it so hard to understand what we are saying ? For once it's pretty clear and without many diverging opinions.

- it's not sufficiently useful to warrant another language features (you know, less is more)

- it's yet another sigil and we hate them. 

Le lun. 25 avr. 2022 à 17:14, Austin Ziegler <halos...@gmail.com> a écrit :

[Michael Malter]

That's right. I meant small.

And yes believe it or not, the first (second maybe) marketing campaign for Java was titled "Java is simple". :) 

[zxq9]

On 2022/04/26 0:45, Austin Ziegler wrote:
> That said, it took me a *long* time to understand `=:=` because it’s a

> complex, compound sigil (not used _that_ frequently) that I’ve never
> seen in any other language (and I know quite a few). To _me_, `^Value ->
> …` is clearer than `NewValue when Value =:= NewValue`. But that’s me.

Sorry, but no.

One of the only two places you might do what you wrote above is in a
lambda, which is the whole thing about shadowing VS matching in lambda
heads -- which apparently nobody has caught on to yet but I keep trying
to mention is the original sin here to begin with:

foo(Value) ->
Blah =
fun
(V) when V =:= Value -> foo();
(_) -> bar()
end,
Blah(V).

The other place you *might* do that (but almost never would if you have
a half-decent design to your data) is if you are trying to do a multi
match on a common value in an argument list entering a function and
at least one of the values is buried in a larger structure like a map
or binary (so the matching procedure will perceive one of them as
unassigned). I forget the details of this particular case, but the
compiler tells you whenever this occurs, and it is rare enough that I
can quite happily say that remembering the rules of when this can
occur is something I never have to do.

Anyway, two cases, one is pretty obvious, somewhat common, and has an
obvious and *simplifying* solution (have matching in lambda heads
instead of shadowing), and the other case is pretty rare in practice
but can already be solved with guards (and could also be solved in a
*simplifying* way by making the specific matching procedure that fails
in the odd case work as expected -- though IIRC the reason it doesn't
is some efficiency tradeoff, so whatever, who cares).

The point is "leave 'well enough' alone" and your example illustrates
enough unfamiliarity with the language you want to change that I just
don't get the point of even pushing for it other than for *your*
personal comfort in a language that you already stated is not your main.

As for you not grokking the point of == VS =:= ... it is really hard
to even see this as a serious argument. It's troll-level nonsense and
brings us right back to plenty of people not having any clue what the
little ^ is supposed to imply in Erlang. Just a "right back at'cha"
moment there.

A: "I don't understand what ^ is."
B: "I don't understand what =:= is."
A: "It just means 'match', AKA type+value comparison."
B: "Oh. Well, if you don't accept ^ into your language you're hateful."
A: "Wait... what?!?"

-Craig

[zxq9]

That's an interesting idea.

<<"foo">> is clearly not "foo", nor are other semantically equivalent
iolists, and you should have reform one to the other before expecting
them to compare equal (with either operator). A pretty strong argument
could be made for numerical comparisons working in the same "all
comparisons are strict" way, though this would be definitely considered
a wart of value semantics by some folks.

I think the ambiguity would creep in with "what to do with >, <, >=, and
=<?" I mean, true type order would imply something very different from
value comparison half the time, which is sorta kinda an ambiguity...

Anyway, this is an interesting idea. There are indeed *very* few places
that == is used where =:= wouldn't be appropriate as well.

-Craig

[Michael Malter]

It's fine. Let's try to keep a cool head.

I think your posts added to the general comprehension of the problem Austin.

I have also been guilty of being a little less diplomatic than usual here. In the end, it's not a democracy but I have a feeling that most people are against that eep. I have asked three of my friends. That's what I call serious statistical sampling :) 

Le lun. 25 avr. 2022 à 19:07, Austin Ziegler <halos...@gmail.com> a écrit :

[Michael Truog]

On 4/24/22 16:38, zxq9 wrote:
> From the EEP, which is about "pinning operators" (will the nonsense
> cease?):
> > In Erlang, they would be optional
>
> So why would you even want this? The entire idea is stupid, *implies* a
> break with the basic rules already built into the language, and appears
> to be nothing more than a way to roadmap the destruction of Erlang over
> time with gee-whiz glyphy syntax of the sort which Erlang has been thus
> far generally free.
>
> That's a big "NO" from me on this EEP, but I imagine anyone could have
> already guessed that. Thanks for the heads up. I don't expect sanity to
> prevail over time -- it is just the trend of the times -- but it was
> interesting to at least see this mentioned to those of us still
> subscribed to the bad dirty old ML.

That motivation to add the "pinning operator" to Erlang is really
motivation to create a smaller function where the pinning operator is
not necessary.

Adding the "pinning operator" to Erlang would not improve the language,
because the operator's intent is to help people create larger more
complex functions.  This fundamental problem can not be ignored by
creating a new mailing list discussion thread.

Don't fear the refactoring!  Embrace improving source code!

Best Regards,
Michael

[zxq9]

I'm assuming you meant your response to be to the list but maybe missed
that in a rush to respond (I know, things can sure get heated when
someone is wrong on the internet!).

On 2022/04/26 3:29, Austin Ziegler wrote:

> On Mon, Apr 25, 2022 at 2:23 PM zxq9 <zx...@zxq9.com
> <mailto:zx...@zxq9.com>> wrote:
>
> On 2022/04/26 0:45, Austin Ziegler wrote:
> > That said, it took me a *long* time to understand `=:=` because
> it’s a
> > complex, compound sigil (not used _that_ frequently) that I’ve never
> > seen in any other language (and I know quite a few). To _me_,
> `^Value ->
> > …` is clearer than `NewValue when Value =:= NewValue`. But that’s me.
>
> Sorry, but no.
>
>

> Sorry, but you don’t actually get to tell me what I think is clearer.
> Full stop.

I get to point out when your argument leans on an un-idiomatic construct
and demonstrate how the idiomatic way makes this a non-issue at its
root.

Did you even read what I wrote? I gave an idiomatic example.

> As I said, I don’t really care about this EEP. I do care that people
> have been arguing this emotionally (while pretending not to do so) and
> have taken sideswipes against other languages that have made different
> choices.

Emotional? The only emotion I'm feeling right now is mirth, buddy.

Me: [points out how your example makes no sense]
You: STOP BEING EMOTIONAL!
Me: OK, bro. [chuckles in Erlangistani]

> The Erlang core development team has expressed some interest in this
> EEP. Wouldn’t it be more productive to take it up with them on the
> forum, and provide them actually *useful* arguments?

The CoC bans those of us who disagree with the DIE and ESG religion
from participating in the forums. So, no.

I mentioned all this before.
You never read what I wrote.
That's been a theme in this super weird thread.

> It’d be more fun than the soliloquizing that I’ve seen so far.

Sorry, you're going to have to use fewer $2 words; we conservative
minded folks are too stupid to understand what you're saying if it
doesn't involve cheeseburgers, pro-wrestling or Orange Man metaphors.

-Craig

[Oliver Korpilla]

Congratulations, all of you.

You manage quite well what hasn't happened before: Making this list irrelevant. The forums didn't quite do that. But your spammy posts that flood everybody's mailboxes do.

I bet quite a few reasonable people would have dropped from the list by now.

I honestly don't care about whether you think if a simple optional operator ruins your true faith or will save us all.

Just stop the spam battle and by Jove stop reposting messages that actually managed to miss the list to keep fanning this flame war.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Fred Dushin]

So I am a little confused.  Reading the EEP,

f(X, Y) ->

    case X of

        {a, Y} -> ok;

        _ -> error

    end.

means the same as

f(X, Y) ->

    case X of

        {a, ^Y} -> ok;

        _ -> error

    end.

So it adds nothing semantically to the language.

The more compelling example is binding a clause head in a local function definition to a previously bound variable.  From the EEP:

f(X, Y) ->

    F = fun ({a, ^Y})  -> {ok, Y};

            (_) -> error

        end,

    F(X).

But as noted later in the EEP, this can be written as

f(X, Y) ->

    F = fun ({a, Z}) when Z =:= Y  -> {ok, Y};

            (_) -> error

        end,

    F(X).

So as far as I can see, the proposal is at best proposing syntactic sugar over what can already be accomplished in the language.  Current Erlang might be more verbose (by character count), but to say it is more or less clear is in the eye of the beholder, certainly.

I think the real question is whether the language should admit two ways of accomplishing the same thing (and by that, I mean compiling to effectively the same BEAM ASM), and that is really up to the language maintainers.

If you want my personal opinion (I know, you didn't ask), I lean on the side of "Less is more", when it comes to language features.  Having to read Scala in my day job, I can't think of a programming language that more violates the principle of linguistic parsimony -- it even puts C++ to the test!

And not to be too critical, but I am having a hard time understanding parts of the Rationale section.  The author(s) suggest(s) that in current Erlang temporary variables are needed to achieve the same as the proposed glyph, but then provide an example that uses a guard (as above) but doesn't use a temporary variable, after all (?)

I am not sure what the problem is with temporary variables.  The compiler has registers at its disposal, so I don't think it's a performance argument, but more an issue of readability, which again, I think is a purely aesthetic question, and has no bearing on the features of the language, per se.  In other words, the proposal is not suggesting anything that cannot already be achieved in current Erlang, with effectively the same compiled BEAM ASM.

Also, kind of a stupid question, but wouldn't

f(X, Y) ->
    case X of

        {a, Y} -> ok;
        _ -> error
    end.

be more clearly written:

f({a, Y}, Y) -> ok;
f(_, _) -> error.

I would never write the former, if I had the option to write the latter, but that just may be my personal preference.

-Fred

[Attila Rajmund Nohl]

Fred Dushin <fr...@dushin.net> ezt írta (időpont: 2022. ápr. 27., Sze, 15:14):
>
[...]

> But as noted later in the EEP, this can be written as
>
> f(X, Y) ->
> F = fun ({a, Z}) when Z =:= Y -> {ok, Y};
> (_) -> error
> end,
> F(X).

[...]

> And not to be too critical, but I am having a hard time understanding parts of the Rationale section. The author(s) suggest(s) that in current Erlang temporary variables are needed to achieve the same as the proposed glyph, but then provide an example that uses a guard (as above) but doesn't use a temporary variable, after all (?)

Z is the temporary variable in the above example.

> I am not sure what the problem is with temporary variables. The compiler has registers at its disposal, so I don't think it's a performance argument, but more an issue of readability, which again, I think is a purely aesthetic question, and has no bearing on the features of the language, per se. In other words, the proposal is not suggesting anything that cannot already be achieved in current Erlang, with effectively the same compiled BEAM ASM.

Naming is hard, and if you have to come up with two meaningful
variable names instead of one, it's even harder. This leads to code
like this:

F = fun ({a, TmpMeaningfulName}) when TmpMeaningfulName =:=
MeaningfulName -> {ok, MeaningfulName};

The current solution in the language easily leads to too long lines or
overly verbose code.

[Dmytro Lytovchenko]

Would it provide a solution to just assume that the variable shadowing is never wanted?

What if code like:

    f(X) -> fun(X) -> X end.

    g(Y) -> case h() of Y -> %code% end.

1. Could create an error due to X being shadowed.

2. Could compile with inner X shadowed but a guard is added by the Erlang compiler, comparing inner to the outer:

    f(X) -> fun(X2) when X2 =:= X -> X2 end.

    g(Y) -> case h() of Y2 when Y2 =:= Y -> %code% end.

3. Current behaviour: Inner X is shadowed and is an entirely new variable (leads to naming and scoping confusion)

Solution 2 does not introduce new syntax and matches expectations for many developers. The compiler fixes the confusion during the compile time. Also should not break the existing code.

[Richard O'Keefe]

I can't recall everything I said against this EEP,

but there are two issues I can think of right now,

and a better alternative.

(A) Inconsistency.

    Suppose a variable occurs multiple times

    in a single pattern.  What does it mean if

    it is "pinned" in some of those occurrences

    but not others?  Are there two different

    variables?

    Suppose a construct has multiple clauses,

    and a variable is "pinned" in some of those

    clauses but not others.  Are there two

    different variables?

(2) There are other problems with scope that we

    want to address, but "pinning" does nothing

    for them.  (The classic one is people

    expecting variables to be local to a 'case'

    but leaking out.)

The counter-proposal is quite simple.

(A) Fix the original problem.  Erlang had a very

    simple scope rule: the scope of a variable is

    the *entire* top-level function clause it

    occurs in.  Reinstate that rule.

    This is a breaking change, so it needs some

    sort of -simple_scopes declaration to enable it.

    We now have a feature declaration that can be

    used for this.

(B) Fix the locality problem.  The right way.

    By declaring which variables are *local*,

    not which variables are *not* local.

    Borrowing some syntax from Prolog (as Erlang

    originally got its syntax thence), let D be

    a syntactic form made of tuples, lists, and

    variables, and C be a pattern or expression.

    Then D ^ C means that each of the variables

    in D represents a new variable in C, not

    provided, visible, or in any way accessible

    in C.

With this approach, local scope is available for

*every* construct.  With the scope marker being

located at the *beginning* of a construct, instead

of being buried possibly deeply inside, it should

be easier to read.

[Raimo Niskanen]

On Fri, Apr 29, 2022 at 12:00:39AM +1200, Richard O'Keefe wrote:
> I can't recall everything I said against this EEP,
> but there are two issues I can think of right now,
> and a better alternative.

:

> The counter-proposal is quite simple.

:

> (B) Fix the locality problem. The right way.
> By declaring which variables are *local*,
> not which variables are *not* local.
> Borrowing some syntax from Prolog (as Erlang
> originally got its syntax thence), let D be
> a syntactic form made of tuples, lists, and
> variables, and C be a pattern or expression.
> Then D ^ C means that each of the variables
> in D represents a new variable in C, not
> provided, visible, or in any way accessible
> in C.
>
> With this approach, local scope is available for
> *every* construct. With the scope marker being
> located at the *beginning* of a construct, instead
> of being buried possibly deeply inside, it should
> be easier to read.
>

Could you show a small example?
I do not realize what this would look like...

Cheers
--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

[Chris Rempel]

As some of the more recent messages have stated, the pinning operator is the wrong solution to the problem.  Clearly, we need to be rid of variable shadowing, then all that remains is subjective readability which can be addressed with generic annotations or tooling (syntax highlighting, linting etc).  Other scoping improvements can be made as well. The pinning operator opens the door for rebinding variables at a later date.  And that is a fundamental language change.

 

This is all rehashing everything that was said the last time around.  And because the EEP process does not provide a mechanism for capturing feedback and iterating to a conclusion, this repeated discussion is not beneficial.

 

Regards,

Chris

[Stanislav Ledenev]

Further we go, the worse it becomes. Erlang's community always seems to be
so reasonable. What the hell happened? The problem is not with this particular EEP.
The problem is with the whole process of reasoning behind those EEPs being broken.

Let's take a look at this stupid operator ^.
What do we know about it?
1. It is optional;
2. This operator should clearly state that the variable is already bound.

Don't you see any contradictions?

Does it mean that if this operator is not present then the variable is not already bound?
No, because *the compiler* does the job and it doesn't need this operator.

Ok. But this operator is for humans! Those wonderful people would read a code
and they get their "a-ha" moment when they'll see this beautiful operator.

Oh, wait a moment. But this operator is optional. What will happen if I wont
put it in my code? On purpose or accidentally. NOTHING. No punishment.
Why should I bother then?

This particular EEP's "problem" can be solved like this:

f(X, Y) ->
    case X of

        {a, Y} -> ok; % Y is already bound
        _ -> error
    end.
   
See - no changes to the compiler. Right out of the hat.

I've seen here about the annotations as another "solution". Hell, no. Look at
Java's annotations. You never know what the hell is going on behind this annotation
without source code examination.

Erlang's source code has always been so perfectly clear. Erlang's syntax is brilliantly,
geniously simple! I've never had any problems reading any of Erlang's code - servers, clients,
cryptography, OTP itself, e.t.c.  Of course you must be aware of the domain problem.

So what is this all about? It's all about the community on the path of inventing
problems and defeating these imaginary problems. Defending from extraterrestrials.
Grief from mind.

Please stop it.

пт, 29 апр. 2022 г. в 09:33, Chris Rempel <cs...@gmx.com>:

[Eric Pailleau]

+1

Envoyé depuis mon mobile

---- Stanislav Ledenev a écrit ----

[Loïc Hoguin]

On 28/04/2022 14:00, Richard O'Keefe wrote:
> (A) Fix the original problem.  Erlang had a very
>     simple scope rule: the scope of a variable is
>     the *entire* top-level function clause it
>     occurs in.  Reinstate that rule.
>     This is a breaking change, so it needs some
>     sort of -simple_scopes declaration to enable it.
>     We now have a feature declaration that can be
>     used for this.

This is the solution I would prefer with regard to solving locality and
shadowing. But I am well aware that this would not solve the original
issue, in particular it wouldn't help avoid accidental matching of
variables that were already bound. What's at the beginning of the rationale.

There would still need to be a compiler warning/error (should really be
an error if not already) about exporting variable from case clauses
where the variable is not defined in all clauses, though, but that's fine.

> (B) Fix the locality problem.  The right way.
>     By declaring which variables are *local*,
>     not which variables are *not* local.
>     Borrowing some syntax from Prolog (as Erlang
>     originally got its syntax thence), let D be
>     a syntactic form made of tuples, lists, and
>     variables, and C be a pattern or expression.
>     Then D ^ C means that each of the variables
>     in D represents a new variable in C, not
>     provided, visible, or in any way accessible
>     in C.

This would also be acceptable but I too would like to see what it would
look like. I fear that it may end up much more complex to the developer
than the first solution. Also it probably doesn't solve the original
issue in the rationale.

[Nicolas Martyanoff]

Stanislav Ledenev <s.le...@gmail.com> writes:

> Further we go, the worse it becomes. Erlang's community always seems to be
> so reasonable. What the hell happened? The problem is not with this
> particular EEP.
> The problem is with the whole process of reasoning behind those EEPs being
> broken.

At the risk of repeating myself, one of the major issue behind this kind
of debate is that the discussion is made of everyone but whoever is
actually in charge of deciding whether to adopt or not the change.

EEP-0055 was created in Decembre 2020, i.e. 16 months ago. It feels to
me that the only response we have had from the OTP team is some kind of
"maybe, maybe not, we'll decide later".

In most open source communities I follow, people in charge are able to
provide authoritative responses on much shorter time frames, and
communicate clearly on the vision behind the project. This way, everyone
knows what to expect, whether they agree or not.

Letting "the community" (a bunch of people who do not have the
authority to actually decide one way or another) argue on the subject
for 16 months is really damaging:

- Nothing productive is coming out of it.

- Relations are being damaged due to more and more heated exchanges.

- At the end of the day, we still do not know when (if) the OTP team is going
to make up its mind and rule on the subject.

On a personal basis, if this EEP was adopted, it would be a clear signal
for me to stop investing in Erlang for the future. But my personal
opinion is irrelevant: it is up to the OTP team to decide so that
everyone can act on it.

--
Nicolas Martyanoff
http://snowsyn.net
kha...@gmail.com

[Richard O'Keefe]

I should make it clear that my "counter-proposal" is

meant to demonstrate that the possible solution space

relevant to the EEP has NOT BEEN ADEQUATELY EXPLORED YET.

If it were fully worked out, the counter-proposal would

be an EEP itself.

I'm not saying "there is no problem" or "let's never do

anything new" or "Erlang is perfect".  (I've written a

lot of EEPs myself.)

I'm saying something that should be fairly easy to

accept: *this* EEP is nowhere near ready for acceptance.

Frames were an EEP, and we got maps instead (which I am

still miffed about, but everyone else seems to be very

happy).  And we got them a long time after a fairly

detailed Frames design was provided, because the maintainers

wanted one mechanism that solved two different things, not

the one thing that Frames were designed for.

For what it's worth, I had a three-part proposal for

adding something very like assignment to Erlang, starting

with X := e handled by renaming, and proceeding to

assignment of substructures using lenses.  I never got

around to writing it all up, because honestly, there are

just better ways to write Erlang than the ways that would

have been helped with this.  And I can tell you that the

"pinning" operator would not have been useful for this at

all, but on the contrary, a major pain to deal with.

No, an EEP that was never submitted is not a good reason

to reject an EEP that *was*.  All it can be is a reminder

that the space of possible solutions should never be

constrained to "what the cool kids are using".