> %{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.
