Es6_maps - EcmaScript6-style shorthand map literals

Is there a reason why you have created a custom mix task for formatting instead of writing a plugin for .formatter.exs file?

By the nature of this solution it’s tightly coupled to the internal Elixir implementation. The current version of es6_maps should work for Elixir 1.15, 1.16 and the upcoming 1.17 version, but may break in the future.

Could you please add some kind of verification to the compile task (with special form maybe?), so the code would not fail in said task and it would automatically call --revert and print a warning instead? Is it possible in this case?

Is there a reason why you have created a custom mix task for formatting instead of writing a plugin for .formatter.exs file?

A couple:

• It’s very hard to pass-through formatting when implementing Mix.Tasks.Format behaviour. If your plugin says it handles [".ex", ".exs"] extensions, it will take over these extensions completely, and the original formatter won’t run anymore.
  In its initial incarnation the formatter only concerned itself with maps, leaving the rest of the formatting up to the default formatter. It’s true that the current version basically does the whole format though, calling Mix.Format just in case…
• But more importantly, I included a formatting task as a way to jump all-in, but primarily as a guarantee for people that they’ll be able to jump out if needed. I did see that as a one-off, explicitly called task.

That said, with the current implementation it might make sense to both have the task and an optional formatter for people to use, sharing the same code.

Could you please add some kind of verification to the compile task (with special form maybe?), so the code would not fail in said task and it would automatically call --revert and print a warning instead? Is it possible in this case?

It is possible, but I don’t think I can sensibly guard / detect against incompatible changes in the compiler without knowing what the changes would be. Also note that es6_maps only modifies the compiler that runs in a separate pass, it doesn’t compile things by itself.

To be clear, if I could detect that the code would fail to compile due to the shorthand-form maps I wouldn’t reformat user’s on-disk files anyway – and, if I found a good way to modify AST and pass it to the compiler, I would have rewritten the whole library to use that mechanism instead and there wouldn’t be a need for a fallback in the first place.

Will LSP server (e.g. elixir-ls) work with this library?

This is awesome!

Will LSP server (e.g. elixir-ls) work with this library?

I’m using ElixirLS, and while it doesn’t pick up e.g. hello in %{hello} = %{hello: 1} as a new variable for autocomplete, it also doesn’t throw up any warnings or errors to the user - because the syntax is correct and the code compiles. It does however complain about the line in its internal warning output.

Getting more support in an LS is an interesting point of improvement. I wonder if I could influence it from the “outside” similarly to how I do the compiler.

Is there a reason why you have created a custom mix task for formatting instead of writing a plugin for .formatter.exs file?

Following our discussion, I have just released v0.2.2 where the custom format task is replaced with a formatting plugin that can be additionally configured inline with comment pragmas.

I looked at the implementation, and I must say that I’m impressed by the flexibility of Elixir and BEAM. It’s wicked, but it’s good to know that you can modify the behavior this deeply.

These shorthand map keys look extremely useful to me personally, I find that my map keys and variable names are often the same. Are there any prior discussions about making this shorthand notation part of “standard” compiler? Would be interesting to know why developers decided against it.

This discussion is at least as old as elixir is stable. This is from just a few month after 1.0 and it still mentions earlier proposals as well: https://groups.google.com/g/elixir-lang-core/c/NoUo2gqQR3I

I believe this is the most recent extended discussion complete with proposal and poll: https://forum.elixirforum.com/t/proposal-add-field-puns-map-shorthand-to-elixir/15452

FWIW, I think this feature could likely get accepted into Elixir. The main problem IMO is that most people want bare words, but Jose wants there to be a visible distinction so it’s clear what the key type is. I think if someone proposed the ruby style syntax for this instead and was willing to do the work to implement it, it’d be accepted.

Basically, instead of:

iex> foo = 1
iex> %{hello, bar} = %{foo, hello: "world", bar: 2}

do:

iex> foo = 1
iex> %{hello:, bar:} = %{foo:, hello: "world", bar: 2}

I don’t see anywhere in your examples anything about the pin operator (^), map update syntax %{x | foo: 1}, structs %Foo{bar: 1}, or struct update syntax %Foo{baz | bar: 1}. If they’re not supported, I’d argue they should be added.