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