> 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-core+unsubscr...@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-core+unsubscr...@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.
