Honestly, I do not adore the syntax of the proposed solution, in either capture or $ operator incarnation. I would also prefer barewords.
*Re: Paul's note:* > It is not at all clear to me why supporting string keys is critical to the feature 100%, Phoenix params parsing support. This is the major obvious use-case for full-stack devs today of this proposal. If garbage collection of atoms is implemented in erlang, we could deprecate the proposed syntax readily. Most of my personal Elixir development does not use Phoenix, so I do empathize with the sentiment and prefer atoms/barewords, but have tried to accommodate the outcry for this feature in this proposal, contending with popularity of JS's barewords implementation, concerning fullstack Phoenix development on > the Elixir forum (1 <https://elixirforum.com/t/proposal-add-field-puns-map-shorthand-to-elixir/15452> , 2 <https://elixirforum.com/t/shorthand-for-passing-variables-by-name/30583>, 3 <https://elixirforum.com/t/if-you-could-change-one-thing-in-elixir-language-what-you-would-change/19902/17> , 4 <https://elixirforum.com/t/has-map-shorthand-syntax-in-other-languages-caused-you-any-problems/15403> , 5 <https://elixirforum.com/t/es6-ish-property-value-shorthands-for-maps/1524> , 6 <https://elixirforum.com/t/struct-creation-pattern-matching-short-hand/7544> ) *Re: José's note:* > I agree with Paul that we don't need to support both strings and atoms, but it must be clear that it applies to either strings or atoms. I would also prefer only supporting atoms, or even as a compromise with string confusion, only structs. Previous proposals have flighted this before, and have not succeeded. I would argue that if we want to support only atoms, but make it clear that the syntax only applies to atoms, before an Elixir 2.0, we must leverage atom literals in the feature. The addition of a new operator (or, overloading of the capture operator in previous incarnations of this proposal) is the only way to accomplish this today. If we really wanted to drive this home, we could only support atom literals in the proposal, and drop the support for strings; however, I don't see a way to resolve this tension today without employing atom literals in the feature's syntax. *Re: Paul's note:* > I really don't want this thread to devolve into argument like many of the others on this topic, but making statements like "a barewords implementation is not viable in Elixir" is not doing any favors. It is factually untrue, and the premise of the statement is based entirely on an opinion. If this thread is going to have any hope of making progress, broad assertions of that nature better be backed up with a lot of objective data. I wish there were a data-driven way to approach language design. The only tool I know of is flighting proposals with working prototypes. > Make the case why *extra* syntax is better than the more limited barewords-only implementation, for example, by enabling support for string keys, by offering a syntax construct that can be used in more places, etc. It isn't necessary for your proposal to torpedo other solutions in order to succeed, and has a better chance of doing so if you don't. This proposal makes a case for this syntax being better than a more limited barewords-only implementation. Specifically, it enables support for string keys, and offers a syntax construct that can be used in more places (as a specific example, error = "rate limit exceeded"; $:error # return error tuple. Apologies if it feels like I am trying to torpedo other solutions, that is not my intent at all. On Thursday, June 29, 2023 at 2:02:04 AM UTC-5 José Valim wrote: > Hi Chris Keele, thank you for the excellent proposal. I just want to add > that I agree with Paul that we don't need to support both strings and > atoms, but it must be clear that it applies to either strings or atoms (if > it supports only one of them) and the reason for that is because otherwise > it will add to the string vs atom confusion that already exists in the > language. Someone would easily write def show(conn, %{id}) and be surprised > why it doesn't match. > > A couple additional thoughts to the thread: > > * : in JS and = in Haskell/OCaml are operators. : in Elixir is not an > operator > > * &:foo/$:foo as a shortcut for {:foo, foo} is interesting but note that > "foo: foo" already work as a shortcut in select places - so we would > introduce more ways of doing something similar > > * Elixir and Ruby shares a lot syntax wise, it may be worth revisiting > what they do and which points arose in their discussions/implementations > > On Thu, Jun 29, 2023 at 8:51 AM Paul Schoenfelder < > paulscho...@fastmail.com> wrote: > >> For reasons explained in Austin's reply >> <https://groups.google.com/g/elixir-lang-core/c/P6VprVlRd6k/m/ijxO7HdpAgAJ>, >> a "barewords" implementation is not viable in Elixir, because of the >> prevalence of both atom and string key types. >> >> IMO, discussing the nuance of if a barewords representation should prefer >> atoms or keys is what has been continually holding this feature up for a >> decade, and that's what this proposal tries to move past. >> >> >> I don't agree that the rationale given by Austin is sufficient to reject >> a barewords-only implementation of field punning in Elixir. It is not at >> all clear to me why supporting string keys is critical to the feature, and >> I especially don't find the argument that people will ignore all of the >> plentiful advice about avoiding atom table exhaustion just so they can use >> field punning (e.g. switching to `Jason.parse(.., keys: atoms)`) >> compelling, at all. There will always be people who find a way to do dumb >> things in their code, but languages (thankfully) don't base their designs >> on the premise that most of their users are idiots, and I don't see why it >> would be any different here. >> >> I've seen this debate come up over and over since the very first time it >> was brought up on this list, and there is a good reason why it keeps dying >> on the vine. The justification for field punning is weak to begin with, >> largely sugar that benefits the code author rather than the reader, and >> syntax sugar must carry its own weight in the language, and the only chance >> of that here is by building on the foundations laid by other languages >> which have it. Doing so means readers are much more likely to recognize the >> syntax for what it is, it adds no new sigils/operators, and it is narrowly >> scoped yet still convenient in many common scenarios. If anything, the >> desire to make this work for string keys is what keeps killing this >> feature, not the other way around. >> >> I really don't want this thread to devolve into argument like many of the >> others on this topic, but making statements like "a barewords >> implementation is not viable in Elixir" is not doing any favors. It is >> factually untrue, and the premise of the statement is based entirely on an >> opinion. If this thread is going to have any hope of making progress, broad >> assertions of that nature better be backed up with a lot of objective data. >> Make the case why *extra* syntax is better than the more limited >> barewords-only implementation, for example, by enabling support for string >> keys, by offering a syntax construct that can be used in more places, etc. >> It isn't necessary for your proposal to torpedo other solutions in order to >> succeed, and has a better chance of doing so if you don't. >> >> Paul >> >> On Thu, Jun 29, 2023, at 12:40 AM, Christopher Keele wrote: >> >> > This proposal mentions OCaml, Haskell and JS as prior works of art for >> > this type of feature. I think a key thing to point out is that in those >> > languages, they did not need to add additional syntax in order to >> > support this. >> >> This is true, and the discomfort extends to Ruby as well. >> >> For reasons explained in Austin's reply >> <https://groups.google.com/g/elixir-lang-core/c/P6VprVlRd6k/m/ijxO7HdpAgAJ>, >> a "barewords" implementation is not viable in Elixir, because of the >> prevalence of both atom and string key types. >> >> IMO, discussing the nuance of if a barewords representation should prefer >> atoms or keys is what has been continually holding this feature up for a >> decade, and that's what this proposal tries to move past. >> >> Perhaps in an ideal Elixir 2.0 future if we get garbage collection of >> atoms like Ruby, Phoenix can move over to parsing params with atom-based >> key pairs, we can drop the operator and atom/string differentiation, and >> move the entire syntax over to barewords. Worth calling out that this >> proposal (with a new operator, not the capture operator) could remain >> backwards-compatible with the proposed syntax if we moved into an >> atom-oriented Phoenix params parsing Elixir 2.0 future. >> >> As Elixir 2.0 may never get released, famously, this is the only clear >> path I see forward for our production applications today to get field >> punning, that skirts issues with prior art. >> On Wednesday, June 28, 2023 at 11:27:48 PM UTC-5 me wrote: >> >> This proposal mentions OCaml, Haskell and JS as prior works of art for >> this type of feature. I think a key thing to point out is that in those >> languages, they did not need to add additional syntax in order to >> support this. >> >> In OCaml, the syntax goes from >> >> { foo = foo; bar = bar } >> >> to >> >> { foo; bar } >> >> Haskell starts with >> >> C { foo = foo, bar = bar } >> >> and turns into >> >> C { foo, bar } >> >> And lastly, Javascript uses >> >> { foo: foo, bar: bar } >> >> which can be used as >> >> { foo, bar } >> >> Note the lack of additional syntax surrounding these features. >> >> > {foo, bar, baz} = {1, 2, 3} >> > >> > %{$:foo, "fizz" => "buzz", $"bar", fizz: :buzz} >> > # => %{:fizz => :buzz, :foo => 1, "bar" => 2, "fizz" => "buzz"} >> >> If I were coming from one of the above languages (or any other language >> that supports this feature), I would not look at this syntax and say >> "This is field punning". I would have no intuition what is going on. >> >> Speaking as someone that has a decent amount of Elixir experience, >> $"bar" looks like it should be closer in functionality to :"bar" than >> field punning. Or maybe even similar to using ? to find the codepoint of >> a single character. Something to keep in mind, Erlang actually uses $ >> for the same purpose that Elixir uses ?. I'm not saying Elixir couldn't >> use the same token/operator for a different purpose, I just think it is >> something that should be considered. >> >> Justin >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-co...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/aee0f98a-9b9b-4ff0-9a48-08d4e31df8c5n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/aee0f98a-9b9b-4ff0-9a48-08d4e31df8c5n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-co...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/72586965-c3ee-42c0-b7d3-7e863ace2706%40app.fastmail.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/72586965-c3ee-42c0-b7d3-7e863ace2706%40app.fastmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/7134e702-f9b2-44ad-bf33-3b8a633862d7n%40googlegroups.com.
