New EEP draft: Pinning operator ^ in patterns

Raimo Niskanen raimo+erlang-questions@REDACTED
Mon Jan 18 12:25:44 CET 2021


On Mon, Jan 18, 2021 at 11:36:03AM +0100, Loïc Hoguin wrote:
> On 18/01/2021 10:47, Raimo Niskanen wrote:
> > On Sat, Jan 16, 2021 at 02:32:21AM +0900, zxq9 wrote:
> >> On 2021/01/16 0:35, Raimo Niskanen wrote:
> >>> 1) Would the language be a better language with a mandatory pinning operator?
> >>
> >> At the cost of *adding* something arbitrarily hard to research[1] syntax
> > 
> > There, again!.
> > Someone sidetracked right off into "it is bad to add this feature".
> 
> I do not understand what you are trying to say. In my mind, if someone 
> thinks a feature is bad, then it doesn't make the language better for 
> them, and even less so if it's mandatory.

Regarding "mandatory"; I think that it would be worse to have annotation of
matching optional, than to not have it at all.  When I read code and find
annotations in some places, I have to be able to assume that ^X in a
pattern means matching, and X means binding.  The code has to be
consistent, at least throughout a module.

And I do not want to have to figure out which compilation flags were used
since that may be hidden in layers of included makefiles, so it is a hard
problem to prove if a particular flag was used or not.

Therefore it is incorrect to assume that all programers that dislike this
feature as optional dislikes it more as mandatory.  There are also shades
of optional/mandatory: module pragma, compiler flag, warning, etc...


Regarding "add this feature"; when I first learned Erlang back in the late
90's, on my list of top 3 whaaat:s was: is the only way to tell if it is a
bind or a match that I have to manually deduce if the exactly the same
variable name has been used above in the function?  Really?  Some way
of annotating the odd case (matching) would surely be better!

I do not trust my eyes; they deceive me occasinally - I read what I
subconciously want to see.  This was also in the days before en Emacs mode
so no syntax highlighting.  Furthermore I think it is better if a language
does not have to rely on syntax highlighting editors for readability.

So I can say that if Erlang would have had an annotation for matching when
I first learned it, I am fairly convinced I would gladly have accepted that
and thought it was a nice feature to reduce ambiguity.

And I get the feeling that very few in this discussion tries these "first
time" glasses on but instead jumps directly to "this is a bad **change**
because it is a bad feature", or "this is a bad feature (because
**changing** the current..)"



> 
> It would also be very difficult to objectively say it's an improvement 
> or not, because measuring the benefits in this case is not trivial as 
> I've previously stated. So you're only going to get subjective opinions.

True.

> 
> Personally I'm all for the optional warning (current version of the 
> warning), I'm OK with the operator if it was added along with proper 
> local scoping but would likely not use it outside of that scenario (in 
> my projects), and as such I would be very unhappy if the operator was 
> mandatory.

These alternative solutions are also worth discussin, especially if they
would adress the same ambiguity.  But sincerely, I thinkt that changing the
Elang scoping rules is way much harder.

> 
> Being able to write "A = 5, A = inc(4)." is what makes the Erlang 
> language the best I've used in my opinion.

I agree we can not loose that!

> 
> So for the "mandatory" part I would say the language would become worse. 
> If optional, the language would become better but only if added along 
> with local scoping (or with a clear plan leading to local scoping, 
> doesn't have to be done all at once), otherwise it's not an improvement 
> in my opinion.
> 

That is a well put opionion that I happen to disagree with.

I have tried to advocate "optionally mandatory withine a module" with
little success...


> Cheers,
> 
> -- 
> Loïc Hoguin
> https://ninenines.eu

Cheers
-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB


More information about the erlang-questions mailing list