Re: New EEP draft: Pinning operator ^ in patterns
Frank Muller <[email protected]>
| Newsgroups | gmane.comp.lang.erlang.general,gmane.comp.lang.erlang.eeps |
|---|---|
| Message-ID | <CAFA6GnCi0yGTkyNjpCTxSk0u=tcExpcD=xpt6YU1+Pu4m8ZYMA@mail.gmail.com> |
Fully agree with you Craig. Let’s keep this beautiful language simple. And when in doubt, listen to Richard O’Keefe. /Frank Friday 15 jan 2021 03:27, zxq9 <[email protected]> wrote : > On 2021/01/15 0:41, Raimo Niskanen wrote: > > On Thu, Jan 14, 2021 at 02:13:47PM +0100, Richard Carlsson wrote: > >> The way I planned it is: > >> 1. Even from the start, pinning will always be allowed, without > requiring > >> any flag to opt in. This does not tell you about existing uses of > >> already-bound variables, but you can start using pinning right away for > >> readability and for avoiding bugs when refactoring. The compiler will > >> always tell you if a pinned variable doesn't exist, so you don't > >> accidentally accept any value in that position. > > > > I do not like an intermediate state where pinning may be used in only > some > > places in a module. Code should be rewritten module wise to keep each > > module consistent. And if a module is using pinning it should be a > > syntactical error to not use pinning where it should be. > > lolwut? > Let's just be clear on this: > The proposed "compromise" to not making the language more complicated > and inconsistent is to only make it complicated and inconsistent > optionally a module at a time? > > No. > > Erlang is valuable because it lacks glyphy nonsense like this. As ROK > and others pointed out we already have a compiler warning for masking > and are free to invent whatever arbitrary label we want in a lambda. So > what imagined problem is this supposed to be solving? > > "If it ain't broke, pretend it is broken until your solution looks > marketable." > > If you want to use Elixir, just use Elixir. > > We really don't need an `-import(useless_nonsense).` pragma. > > -Craig >