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 <
paulschoenfel...@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-core+unsubscr...@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-core+unsubscr...@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-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J9KtN20_9dsew-7uXeND847Eysda1y7uq%3D_B-T5eF6yA%40mail.gmail.com.
