On Thu, Jun 29, 2023 at 3:02 AM José Valim <jose.va...@dashbit.co> 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
>
`:` isn’t an operator in JS, but it is part of the `?:` ternary operator.
In all other contexts (object construction, object deconstruction /
aliasing, case statements in switches), `:` is syntax.
* Elixir and Ruby shares a lot syntax wise, it may be worth revisiting what
> they do and which points arose in their discussions/implementations
>
In many ways it is a shame that Elixir adopted the `%{"foo": bar}` syntax
meaning the same as `%{:"foo" => bar}`, because otherwise we *could* adopt
the Ruby key deconstruction approach for atoms, strings, and charlists
(`%{foo:, "bar":, 'baz':} = %{:foo => 1, "bar" => 2, 'baz' => 3}`) … and
the discussion could be over. :D
-a
> 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
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J9KtN20_9dsew-7uXeND847Eysda1y7uq%3D_B-T5eF6yA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue
--
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/CAJ4ekQutxiEPiT5q8xTHTsaZjShZBUHi297nnP6chKU1aETciw%40mail.gmail.com.
