> 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.
Indeed, the main argument against a "bare" usage of tagged variable
literals (like foo = 1; {:foo, baz} = $:foo; bar #=> 1) is that we could
not roll back this syntax without 2.0 breaking-changes to only support
barewords where applications really want them: within list/map literals
only.
On Wednesday, June 28, 2023 at 11:40:39 PM UTC-5 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/0d8e7a75-9e08-4abb-9b77-66a088a90430n%40googlegroups.com.
