> Just throwing it out there that this notation would make for a very nice MapSet literal. :)
:D I am deeply convinced that this is why python, in its walrus operator attempt <https://docs.python.org/3/whatsnew/3.8.html#assignment-expressions> to keep up with Ruby features, has not offered a response to Ruby's Hash assignment destructuring of {foo:, bar:}: the {} literal syntax in python is already overloaded for both its native associative array literal construct (dicts) and set literal construct (sets), which share {} as delimiters and cause endless confusion already. On Thursday, June 29, 2023 at 3:14:51 AM UTC-5 woj...@wojtekmach.pl wrote: > > %{foo, bar} > > Just throwing it out there that this notation would make for a very nice > MapSet literal. :) > > On 29 Jun 2023, at 10:05, Christopher Keele <christ...@gmail.com> wrote: > > > There is another idea here, which is to fix this at the tooling level. > > > > For example, we could write %{foo, bar} and have the formatter > automatically expand it to: %{foo: foo, bar: bar}. > > I do like this notion, but am worried about fragmentation at the tooling > level. > > I see a syntax addition (even if an ephemeral operator, deprecated with > atom garbage collection) as an elegant way to traverse this. If we lean > into the syntax addition of this proposal, Paul does make a valid point: > > > 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. > > Hence the proposal. However, I think a constructive outcome of this > discussion could be proposing exactly that expansion to tooling > maintainers. :) > > On Thursday, June 29, 2023 at 2:59:39 AM UTC-5 Christopher Keele wrote: > >> > Another idea is to improve Elixir LS itself to suggest the variable >> name itself after ":". So if I type "%{foo:", it immediately suggests " >> foo". So, once again, easy to write, easy to read. >> >> I think this is part of the popularity of the opinion that some such >> syntax should only work for structs: with Elixir LS today, starting to type >> a `key:` in a struct/map literal does indeed suggest from the list of known >> struct keys. I don't see this being impossible in LS tooling today, but >> also don't know much about what is possible with the language server >> protocol today. :) >> On Thursday, June 29, 2023 at 2:54:28 AM UTC-5 José Valim wrote: >> >>> There is another idea here, which is to fix this at the tooling level. >>> >>> For example, we could write %{foo, bar} and have the formatter >>> automatically expand it to: %{foo: foo, bar: bar}. So you get the concise >>> syntax when writing, the clear syntax when reading. Since most editors >>> format on save nowadays, it can be beneficial. Executing code with the >>> shortcut syntax will print a warning saying you must format the source file >>> before. >>> >>> Another idea is to improve Elixir LS itself to suggest the variable name >>> itself after ":". So if I type "%{foo:", it immediately suggests " foo". >>> So, once again, easy to write, easy to read. >>> >>> On Thu, Jun 29, 2023 at 9:49 AM Christopher Keele <christ...@gmail.com> >>> wrote: >>> >>>> > As a counter point: Ruby has added this feature as {foo:, bar:}, >>>> which would have a direct translation to Elixir. Source: >>>> https://bugs.ruby-lang.org/issues/14579 >>>> >>>> As a Rubyist who came to Elixir in the early days for personal projects >>>> before that Ruby syntax was implemented, and has only been professionally >>>> an engineering team manager of python, JS, and TS applications since: I >>>> like the explicitness of Ruby's notation here, but still really hate it >>>> how >>>> it reads and syntax highlights. :`) >>>> >>>> That is just a personal opinion though, out of context of the utility >>>> of this proposal. However, I believe that incarnation for Elixir has been >>>> proposed before, and I am just searching for alternatives that would still >>>> enable field punning sooner rather than later. >>>> >>>> > You are doing great. You defend your proposal and ideas. :) >>>> >>>> Thank you! It is not easy to defend a language syntax proposal I do not >>>> personally adore the syntax of; but I imagine that's what many people felt >>>> like for Ruby's equivalent, with {foo:, bar:} (as I did at the time). >>>> I earnestly believe that this idea could mitigate pain points with Elixir >>>> adoption while reasonably contending with ES6 barewords syntax we are not >>>> yet able to adopt. However, I would not be heartbroken if we agreed that >>>> waiting for Elixir 2.0 and/or atom garbage collection was the right play >>>> here. >>>> >>>> On Thursday, June 29, 2023 at 2:33:22 AM UTC-5 José Valim wrote: >>>> >>>>> > 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. >>>>> >>>>> As a counter point: Ruby has added this feature as {foo:, bar:}, which >>>>> would have a direct translation to Elixir. Source: >>>>> https://bugs.ruby-lang.org/issues/14579 >>>>> >>>>> > Apologies if it feels like I am trying to torpedo other solutions, >>>>> that is not my intent at all. >>>>> >>>>> You are doing great. You defend your proposal and ideas. :) >>>>> >>>>> On Thu, Jun 29, 2023 at 9:29 AM Christopher Keele <christ...@gmail.com> >>>>> wrote: >>>>> >>>>>> 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-co...@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 >>>>>> >>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/7134e702-f9b2-44ad-bf33-3b8a633862d7n%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/d265a338-e815-4e6b-a541-e61e2ec89611n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/elixir-lang-core/d265a338-e815-4e6b-a541-e61e2ec89611n%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/d0d6b9a6-b2d0-4a83-8cc0-f8580e151404n%40googlegroups.com > > <https://groups.google.com/d/msgid/elixir-lang-core/d0d6b9a6-b2d0-4a83-8cc0-f8580e151404n%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/4b0b7343-2d02-4424-9341-8d33c45be40fn%40googlegroups.com.
