This is a separate convo but I don’t see value in adding a primary syntax for sets given we can’t really use it in pattern matching. A syntax for only adding and removing set elements is, IMO, not worth it.
On Thu, Jun 29, 2023 at 11:21 Christopher Keele <christheke...@gmail.com> wrote: > > 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 > <https://groups.google.com/d/msgid/elixir-lang-core/4b0b7343-2d02-4424-9341-8d33c45be40fn%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/CAGnRm4Jfqz6tO7mFf-qprquo1%2BxYR7CKe14fVOAxx9A0YGYw%2Bw%40mail.gmail.com.
