Here's a summary of feedback on this proposal so far.
*Concerning the actual proposal itself* (ie, &:foo # => {:foo, foo}): 2
against re-using the capture operator.
*Concerning the followup of a dedicated operator* (ie, $:foo # => {:foo,
foo}): roughly 2 for and 1 against (because it was not barewords), no major
notes.
- Can support strings, atoms
- Allows mixing strings/atoms
- Key typing explicit
- Works awkward with the pin operator
- Does not look like tuples
- Adds new syntax outside of collection constructs, for working with
tagged tuples for good/evil
Overall, doesn't seem wildly popular, but I do think it does handle most of
the problems of previous discussions well.
It does not cleanly map to anything in other languages, but I view that as
a pro because we want something more expressive than what they provide. I
feel like that is part of the lack of enthusiasm, though: people want
whatever feels most intuitive to them from other languages they've worked
with, and as little new syntax to the language as possible. That's a hard
needle to thread.
*Discussion on this thread about other proposals:*
- *"Barewords"* (ES6-style): %{foo, bar} People still want this, it is
still tricky for the usual reasons, and I don't *think* much new has
been contributed to the discussion in this thread.
- Can only support strings or atoms
- No mixing strings/atoms
- Key typing hidden
- Confusable with tuples
- A new thing I've realized in my prototype is that it does work
better with the pin operator than others, something I haven't seen
discussed.
- "Unmached pair" (*Ruby style*): %{foo:, bar:} This has always been on
the table but I do see more support for it than in past discussions. Also,
personally, my least favorite.
- Lacks string support
- No mixing strings/atoms
- Key typing visually clear
- Does not look like tuples
- Pin operator problems
- "*Pair literals*": %{:foo, "bar"} Some people seem to find this too
magical, some prefer this over my proposed dedicated operator that would
make it more explicit.
- Can support strings, atoms
- Allows mixing strings/atoms
- Typing visually clear
- Does not look like tuples
- Pin operator problems
*New proposals:*
- Adding support *at the tooling level*: 2 against (adding my voice
here). As was well-said, why would I write something that's not the
language's syntax?
- Austin had an idea with using my operator *immediately alongside* the
map % literal to apply it to the whole expression. There are problems
with that, but
- This in turn gave me an idea for a slightly new syntax we could use to
support barewords better. I guess call them *qualified* *barewords* or
something for now:
- %{foo, bar}: barewords string keys
- %:{foo, bar}: barewords atom keys
- %Struct{foo, bar}: barewords struct keys
- Initial thoughts:
- Can support strings and atoms
- No mixing strings/atoms
- Key typing explicit, visually clear but hidden for strings
- Sometimes looks like tuples for strings
- Plays nice with pin operator
- Still requires exploration with existing tokenization rules,
mixing rules, map update syntax
I'd love to see someone champion any one of these syntaxes, put up some
prototypes, get into the details of syntax ambiguities, and see dedicated
discussions of pros/cons of explicit proposals in individual threads!
I may continue investigating a prototype for pair literals (%{:foo, "bar"})
or qualified barewords (%:{foo, bar}) as I get bolder with the erl source
code.
I welcome further discussion about the tagged-variable literal operator ($:foo
# => {:foo, foo}) in this thread, but probably won't contribute too much
more to discussion on other proposals, as I want to focus on concrete
proposals and tinker with prototypes for the more promising follow-ups!
Thanks for the discussion, all!
On Thursday, June 29, 2023 at 9:50:39 AM UTC-5 torres....@gmail.com wrote:
> I was catching up with the other discussions about this, and I'm having
> seconds thoughts about Elixir having this syntax sugar for maps.
> It all sums up to what Austin pointed out here
> <https://groups.google.com/g/elixir-lang-core/c/P6VprVlRd6k/m/hMmgSniMAgAJ>
> .
>
> The bottom line, IMO (and agreeing with Austin), would be to end having
> something like `%{"foo", 'bar', :baz} = %{"foo" => 1, 'bar' => 2, :baz =>
> 3}; {foo, bar, baz} #=> {1, 2, 3}`, to solve the atom/string key problem,
> and given that I'd prefer not to have it and leave Elixir as it is today.
> I also don't see any other tool (like a formatter or a language server)
> doing this kind of job. Why would I write something if that's not the
> language's syntax? If we open this precedent I'm not sure where we may end
> up with (probably would end up like JS: being transcripted by transpilers).
> Plus, the misspelling argument is not appealing enough too, since a good
> test covered application (which IMO should be our desire and intention)
> would have that caught.
> To add a little more, since we should use atoms with caution due to
> platform's limitations, we shouldn't make easier to enforce their usage,
> and since the %{ foo } = %{ foo: "any value" } syntax sugar would favour
> it, I am convinced enough *to not have* this on Elixir, contradicting
> myself in a previous proposal.
>
> Em quinta-feira, 29 de junho de 2023 às 16:24:06 UTC+2, José Valim
> escreveu:
>
>> : is not an operator at the user level for JS but it behaves like one
>> syntactically. You can add or remove spaces on either side and it works.
>> That’s not true for Ruby or Elixir as moving the spaces around is either
>> invalid or has a different meaning.
>>
>
--
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/7f7301bb-82fd-4a9b-9075-6363ac32fbd8n%40googlegroups.com.
