> %{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 <christheke...@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 > > <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 > <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-core+unsubscr...@googlegroups.com > <mailto:elixir-lang-core+unsubscr...@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/3C7C8A92-71EB-4CE1-805B-8004CB7604B6%40wojtekmach.pl.