> In reference to this discussion <https://groups.google.com/g/elixir-lang-core/c/NoUo2gqQR3I/m/ddgTD3DU4oMJ>: > >> This is going to be a big deal for Phoenix. In our channels where we're matching against the message, we have lines like this pervasively: >> >> def handle_in(event, %{"chat" => chat, "question_id" => question_id, "data" => data, "attachment" => attachment, ...}, socket) do... >> def handle_in(event, %{chat, question_id, data, attachment, ...}, socket) do... > >This would allow us to write: > def handle_in(event, %{$"chat", $"question_id", $"data", $"attachment", ...}, socket) do...
As a vanity benchmark, this $ operator syntax is a 30% reduction in line length (from 132 characters to 91) compare to the other "barewords"-proposal's nicer 41% reduction (from 132 characters to 79) for this particular usecase. However, it paves the way for field punning today, rather than waiting for atom-garbage collection, a future Elixir 2.0 release, and Phoenix atom-key-params-parsing support. It also addresses two of the original pain points of this feature that future barewords support would not: 2) Visual clarity <https://groups.google.com/g/elixir-lang-core/c/XxnrGgZsyVc/m/NBkAVto0BAAJ> that atom/string matching is occurring 4) Easy confusion <https://groups.google.com/g/elixir-lang-core/c/XxnrGgZsyVc/m/WRhXxHDfBAAJ> with tuples On Thursday, June 29, 2023 at 12:33:28 AM UTC-5 Christopher Keele wrote: > To update the considerations of this proposal if we adopt a new tagged > variable literal operator > <https://groups.google.com/g/elixir-lang-core/c/P6VprVlRd6k/m/017oS_xmAgAJ> > ($) instead: > > *Pro: solves existing pain points* > > *Pro: works with existing code* > > The newly proposed operator results in a compile-time-error on older > versions of Elixir. All compiling Elixir code today will continue to > compile as before. > > *Cons: does not work well with existing tooling* > > A new operator would require dedicated formatter support and updates to > downstream syntax highlighters. > > *Cons: does not minimize surface area of the language* > > A new operator is more new syntax to learn; although one could readily > argue that this is worth not making the capture operator a more complicated > syntax to learn. > > *Pros: does not overload the capture operator* > > *Open Question: charlists* > > A dedicated operator resolves the previous AST parsing ambiguity compared > to using the capture operator. I have implemented charlist tagged > variable literal support > <https://github.com/elixir-lang/elixir/commit/9176180799e1ba11348034c4aa3aa1bf37f11e87> > > to my new-operator prototype branch > <https://github.com/elixir-lang/elixir/compare/main...christhekeele:elixir:tagged-variable-literals>. > > This would complicate parsing of non-literal expressions like field access > <https://groups.google.com/g/elixir-lang-core/c/P6VprVlRd6k/m/WyqlwZ1iAgAJ> > in > the future nice-to-have feature-set more difficult, but still much more > tractable than re-appropriating the capture operator. > > On Thursday, June 29, 2023 at 12:16:23 AM UTC-5 Christopher Keele wrote: > >> > 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. >> >> Indeed, the main argument against a "bare" usage of tagged variable >> literals (like foo = 1; {:foo, baz} = $:foo; bar #=> 1) is that we could >> not roll back this syntax without 2.0 breaking-changes to only support >> barewords where applications really want them: within list/map literals >> only. >> >> On Wednesday, June 28, 2023 at 11:40:39 PM UTC-5 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/dc81c61b-4e99-4067-9dc1-c176c5822705n%40googlegroups.com.
