Proposal: Short Hand Property Names

276 views
Skip to first unread message

Jason S.

unread,
Jul 12, 2018, 5:40:07 PM7/12/18
to elixir-lang-core
Recently I've been writing way too much JavaScript and they've added a neat feature called "short hand property names" that is a shorter way of creating and de-structuring maps. I believe this is a nice syntax that when coupled with pattern matching can be very handy. THAT SAID I do not have a ton of experience with the Elixir parser so I'm not sure if its possible, hoping the core team can shed some light on this.

Map Creation:

Today when you want to create a new map with specific keys you might do something like this:

greeting = "Hello"
name = "José"
new_map = %{ greeting: greeting, name: name}

Proposed Creation syntax:

greeting = "Hello"
name = "José"
new_map = %{ greeting, name}

The end result is the same, we create a map with symbol keys with the name of the variable and the value of the variable. I particularly find myself making maps very similar to this in Phoenix Views and in ExUnit tests building test data.

Map De-structuring/Pattern matching:

Today when you want to pull a value out of a map you might do something like:
%{greeting: greeting} = new_map

Where greeting now is equal to "Hello".

Proposed De-structuring syntax:
%{ greeting } = new_map

The end result is the greeting key is pulled from the map and the new variable name is set to greeting. With the same semantics as the pattern match.

I find myself building test data in my ExUnit setup steps and each test then has something like: 

test "my thing", %{ conn: conn, user: user, company: company, project: project} do ...

With the new syntax it could be shortened to:

test "my thing", %{ conn, user, company, project} do ...

We could also support mix and matching of these keys like so:

%{ greeting, name: "José" } = new_map

Allowing for slightly more expressive matching as well as shorter lines when trying to set or pattern match against a map.

You can read more about it from MDN https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Object_initializer and the spec for ECMAScript 2015 Object Initializes http://teramako.github.io/ECMAScript/ecma6th_syntax.html#12.1.5

Let me know what you think and if this would be a good "first time parser updater task" for the elixir parser.

Jason (jeregrine)


José Valim

unread,
Jul 12, 2018, 6:32:21 PM7/12/18
to elixir-l...@googlegroups.com
This has been discussed a couple times although I am not sure where. Did you do a quick search here? I can remember at least the discussions that lead to the creation of short_maps and/or shorter_maps libraries.

Implementation wise it should be straight-forward as the parser already handles it:

iex(1)> quote do %{foo, bar, baz} end
{:%{}, [], [{:foo, [], Elixir}, {:bar, [], Elixir}, {:baz, [], Elixir}]}

But my concern is around small issues and inconsistencies this may lead to.

For example, the distinction between maps and tuples becomes a single character:

{a, b}
%{a, b}

In other cases, developers may want to match on string keys (think phoenix parameters) and the proposed syntax considers only atoms. JavaScript does not have this particular problem.

I personally dislike the shortcut syntax for creating maps, as it may ultimately lead to worse code that reuses variables names only to be able to use the shortcut syntax. Finally, I find the map update syntax somewhat awkward too: %{map | greeting, name}.

We should probably look what other languages are doing on this area, as most times we discuss JavaScript as prior art, but we can probably find references that are semantically closer to Elixir.

Thanks Jason!



José Valim
Skype: jv.ptec
Founder and Director of R&D

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/2e9f4505-6da9-4efa-9a68-5e494fcd6f42%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Martin Svalin

unread,
Jul 12, 2018, 6:34:54 PM7/12/18
to elixir-l...@googlegroups.com
This has come up before on this mailinglist, and you may want to read previous discussions.

There is a package that adds this feature via macros: 

This package tends to be mentioned whenever proposals for shorter map syntax comes up:

It was created after a proposal in 2015:

The fact that it comes up again and again is a good signal that a fair number of people like it, but there are also a lot of people who dislike it as you can see in discussion threads. The short_maps package makes it opt-in.

--
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-co...@googlegroups.com.

Justin Wood

unread,
Jul 12, 2018, 10:44:18 PM7/12/18
to elixir-l...@googlegroups.com

We should probably look what other languages are doing on this area, as most times we discuss JavaScript as prior art, but we can probably find references that are semantically closer to Elixir.


I have a few examples if you are looking for prior art here. The term I have seen for it is "field punning"
  • The GHC compiler supports this through an extension[0]
  • OCaml supports it natively[1]
  • I believe Rust supports it[2], but I can't find current documentation around it
I'm sure there are other languages out there that support this is on way or another.


Parker Selbert

unread,
Jul 12, 2018, 10:56:37 PM7/12/18
to elixir-l...@googlegroups.com
That is the first I’ve heard the term “field punning”. After reading the OCaml docs I found this issue for Rust:


Which itself was documenting the “short form” changes in this PR:

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

Andrew Timberlake

unread,
Jul 13, 2018, 1:43:20 AM7/13/18
to elixir-l...@googlegroups.com
I have written a macro library, Shorthand [https://hex.pm/packages/shorthand], that provides short syntax for maps, string-keyed maps, keyword lists and structs. I have found it really helps to reduce clutter when matching on or returning more than one or two keys.

Andrew
--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

José Valim

unread,
Jul 13, 2018, 2:50:53 AM7/13/18
to elixir-l...@googlegroups.com
Thanks Justin.

I like Ocaml's approach because it still keeps the label identifier ~. Translating to Elixir, we could have one of:

1. %{foo:, bar:} and %{"foo" =>, "bar" =>}
2. %{:foo, :bar} and %{"foo", "bar"}

The two examples above are just examples and do not necessarily need to be considered as they still have limitations. For instance, the first is really close to %{foo: _, bar: _}, the second is still ambiguous with tuples. My point here is that whatever solution we pick for Elixir needs to be a bit more explicit, to avoid the conflicts it may arise with other data structures and when comparing atoms/strings, as I explained in my previous e-mail.

Allen Madsen

unread,
Jul 13, 2018, 9:58:07 AM7/13/18
to elixir-l...@googlegroups.com
1. %{foo:, bar:} and %{"foo" =>, "bar" =>}
2. %{:foo, :bar} and %{"foo", "bar"}

I'll say I really dislike both of these options. To me it is incredibly not obvious that having a string or atom literal assigns to a variable of the same name. Also, you can have strings and atoms that are not valid variable names, but with this syntax, I would expect it to work.

If the original syntax suggested is insufficient, I would suggest we use some unary operator similar to the pin operator. Something like:

1. %{`foo, `bar}
2. %{~foo, ~bar}
3. %{$foo, $bar}

This would also allow the syntax to be used with the pin operator, which it wouldn't be obvious for me to do with 1 and 2.

I recognize that there will almost certainly be people who want to use this syntax for strings, but I would still make the argument that this should only work for atoms. Atoms already have a special shorthand in maps that allow you to not use the hash rocket, which strings do not.

I personally would prefer the syntax originally suggested.



--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J8Kd0wmD-9X2JFXUmVCx8KH5hTP5c2YU3kHPoxddmUkg%40mail.gmail.com.

José Valim

unread,
Jul 13, 2018, 10:18:08 AM7/13/18
to elixir-l...@googlegroups.com
Thanks Allen for the input!
 
I recognize that there will almost certainly be people who want to use this syntax for strings, but I would still make the argument that this should only work for atoms. Atoms already have a special shorthand in maps that allow you to not use the hash rocket, which strings do not.

Most of the proposals for this syntax are based on JavaScript. This means most people are being introduced to this feature through JavaScript, which means that, as soon as a developer sees the following in a Phoenix controller:

def show(conn, %{"id" => id}) do
  ...
end

They will rewrite it to the shortcut syntax and they will be puzzled to why it doesn't work. The atoms and strings mapping is already confusing for newcomers, the shortcut syntax will drastically blurry those lines.

We don't need to support both atoms and strings but whatever proposal we accept need to identify visually that we are matching on atoms/keywords. From my perspective, this is a non-negotiable requirement. If we can also support strings, that would be a plus.

As I said, I am not actually advocating for the syntax I proposed earlier. I just wanted to steer the conversation. I think your idea with the unary operator is worth exploring too.

I personally would prefer the syntax originally suggested.

For the reasons above and to help further steer the conversation, there is zero chance the original syntax will be accepted. We need to either come up with something else or accept the feature is not a good fit for Elixir.

Kelvin Raffael Stinghen

unread,
Jul 13, 2018, 10:55:29 AM7/13/18
to elixir-l...@googlegroups.com
What about introducing the exact same way Andrea did on https://github.com/whatyouhide/short_maps, using sigils for it. This way we don’t need to change the maps compiler to support something that it’s causing a division on the community. The only thing we would need to do is merge Andrea’s code to core.

Also, the sigil syntax Andrea chose is really close to the initial proposal, and with a `a` or `s` modifier you can configure if you want atom keys or string keys. Of course you can’t mix atom and string keys on the shorthand, but I guess this is an edge case.

WDYT?

Best,
Kelvin Stinghen
kelvin....@me.com

--
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-co...@googlegroups.com.

José Valim

unread,
Jul 13, 2018, 10:58:55 AM7/13/18
to elixir-l...@googlegroups.com
The library has limitations in regards to nested maps and structs which are hard to circumvent since it is based on strings.

Plus if it works as a library, I see no reason to add it to core. :)
--

Dmitry Belyaev

unread,
Jul 14, 2018, 12:10:15 PM7/14/18
to elixir-l...@googlegroups.com, José Valim
I understand the attempt to make such (possible) feature closer to something mainstream developers are familiar with - it would allow easier transitioning to Elixir from other language.

And that's exactly what such familiar syntax - with small Elixir correction - would do as %{value}.

However the variants with no value after arrow %{:value =>} or literal key only %{:value} look very alien and at least in my case would case a question "and what's the variable name for that". Identifier converted to literal is okay, but the reverse is something very unexpected.

And if we talk about JavaScript developers' expectations, I'm pretty sure they know they are writing Elixir and not JavaScript - they do use %{} and call them maps, they don't try to use JavaScript syntax and don't complain that `o = %{a: 1}; o["a"]` works differently. They know that {a} = {a: a} in JavaScript, so they can learn that %{a} = %{a: a} in Elixir.
--
Kind regards,
Dmitry Belyaev

boris kotov

unread,
Jul 14, 2018, 12:36:51 PM7/14/18
to elixir-lang-core
Maybe something like this:


foo = "foo"
bar = "bar"

map = %{{foo, bar}, "name" => "with short names", age: 12 }
%{{foo, name, age}, bar: bar} = map
%{"name" => named_name, {age}} = map



I think, this is readable, easier to remember and use then the sigils approach and I think it should be easier to implement, because we separate the short_hands explicitly.

José Valim

unread,
Jul 14, 2018, 1:06:42 PM7/14/18
to Dmitry Belyaev, elixir-l...@googlegroups.com
> And if we talk about JavaScript developers' expectations, I'm pretty sure they know they are writing Elixir and not JavaScript

JavaScript developers' expectations is not my only concern. Regardless of the background, the proposed syntax is confusing exactly because there is nothing on the proposed syntax that indicates that we are matching on atoms.

The distinction between atoms and strings is already confusing for many. Constructs like %{key: value, "another-key": value} add to this confusion as they are syntax sugar to atoms. Finally, the similarity of the proposed syntax with tuples doesn't help either.

> However the variants with no value after arrow %{:value =>} or literal key only %{:value} look very alien and at least in my case would case a question "and what's the variable name for that"

Those proposals are not meant to be final. They are just ideas. Don't fixate on them.

I have already been very explicit that the original proposal won't be accepted. Since I have already outlined the requirements, it is probably more productive to everybody if I personally step away from the discussion and let the community work the pros and cons out. Consider newcomers and experienced developers alike. Put yourselves in the shoes of somebody that is accessing a codebase for the first time. Will the shortcut make it easier or will it be foreign? Are we optimizing for writing or reading code? Is the proposed syntax similar to other constructs? If so, which ones? Consider nested data structures matching and complex pattern matching. Ping the creators of short_maps and shorter_maps and get their feedback too.

I don't believe we will have a proposal without cons. So a careful look is necessary. Once a more concrete proposal is made, I will be glad to step in.

Connor Rigby

unread,
Jul 15, 2018, 12:02:50 AM7/15/18
to elixir-lang-core
I really like this idea. I think an extension of this would be great for structs also:
defmodule SomeDate do
   defstruct [:greeting, :name]
end
greeting = "hello, world"
name = "José"
%SomeData(greeting,name)

Christopher Keele

unread,
Jul 15, 2018, 1:48:54 PM7/15/18
to elixir-lang-core
whatever proposal we accept need to identify visually that we are matching on atoms/keywords 

I've been thinking about this and am interested in clarification: does this mean that a proposal would need to employ atom/string literals in the construct? Or do type annotations like the sigil implementation's flags suffice?
 
the proposed syntax is confusing exactly because there is nothing on the proposed syntax that indicates that we are matching on atoms.

I am not against a literal form to indicate this, but I find JS's bareword form much less confusing. This is because it is more important to me to perceive this syntax as affecting the (bareword) variables in scope. When I select the correct key variant it is a once-off thing—when reading code it is often an implementation detail, when refactoring I rarely need to reverse my decision. However, when reading or renaming a variable, I would be liable to miss a construct that I mistook as a simple literal. Full map syntax matches on both literal keys and bareword variable bindings; and since a (lossy) shorthand representation must obscure some piece of information, I would rather obfuscate the key type instead of the fact that we're modifying variable bindings. I see barewords, literals, or new syntax being our only options for this feature; I would rather not have it all than use one of the latter two.

Based on this reasoning I believe the sigil version is the best and least intrusive proposal yet and might merit inclusion in core, with a little work to make it macro-expansion recursive (something I would enjoy contributing). But I am not sure if sigils meet the requirements quoted above without further clarification.

José Valim

unread,
Jul 15, 2018, 2:24:11 PM7/15/18
to elixir-l...@googlegroups.com
> I've been thinking about this and am interested in clarification: does this mean that a proposal would need to employ atom/string literals in the construct? Or do type annotations like the sigil implementation's flags suffice?

No, they do not need to be literally atoms or strings.

Just an example of a possible solution: we could introduce the shortcut syntax only for structs. Structs cannot be confused with tuples because of the struct name. Structs keys are always atoms, so there is no ambiguity with strings. Problem solved. What is the downside? People may want to try to use it for maps and it won't work (but this can be addressed with good error messages).

Now that you mentioned sigils, another solution could even be: %{name, age}a. The "a" indicates atoms and is enough to reduce the confusion with tuples.

Again, I am not necessarily advocating for those solutions. My point is that there are enough options to consider. If at the end of the day none of them are good, so be it, but you have at least considered them.




José Valim
Skype: jv.ptec
Founder and Director of R&D

--
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+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/ced29996-c91a-454c-a01a-09ebeae91e27%40googlegroups.com.

José Valim

unread,
Jul 15, 2018, 2:26:10 PM7/15/18
to elixir-l...@googlegroups.com
> Based on this reasoning I believe the sigil version is the best and least intrusive proposal yet and might merit inclusion in core, with a little work to make it macro-expansion recursive (something I would enjoy contributing). But I am not sure if sigils meet the requirements quoted above without further clarification.

The authors of the sigil ones have run into limitations as people used their libraries, especially when it comes to nested expressions and how sigil terminators work. I would recommend talking to them and asking for their feedback on the pros and cons.



José Valim
Skype: jv.ptec
Founder and Director of R&D

Andrew Timberlake

unread,
Jul 15, 2018, 2:40:13 PM7/15/18
to elixir-l...@googlegroups.com
Have a look at Shorthand. I wrote it recently because I didn’t like the idea of the sigil maps of short_maps being strings. Shorthand is a set of macros that handle nested expressions and can themselves be nested.

Example:
m(one, two, three: m(four), five: nil) == %{one: one, two: two, three: %{four: four}, five: nil}

sm() does the same but creates maps with string keys

kw(one, two) == [one: one, two: two]

s(MyStruct, one, two) == %MyStruct{one: one, two: two}

I’m not advocating for this syntax in the standard library, but having the macros has helped me get what I want in simplifying test and Phoenix params specifically and works very cleanly with matching, formatting, variable identification etc.

Andrew
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KfbqL9M-rToRs_WuuceoUXadTawc7-XZyF_UD0c%3DbPfA%40mail.gmail.com.

Justin Wood

unread,
Jul 15, 2018, 3:20:11 PM7/15/18
to elixir-l...@googlegroups.com
Just an example of a possible solution: we could introduce the shortcut syntax only for structs. Structs cannot be confused with tuples because of the struct name. Structs keys are always atoms, so there is no ambiguity with strings.

I would acutally like if this was done for only structs (and maybe something for records as well, but that is another topic). I think it follows more closely to the three languages that I mentioned earlier in the thread (using it on defined types). I feel like if this were also done for maps, there would be a loss in explicitness.


Yevhenii Kurtov

unread,
Jul 25, 2018, 9:44:04 AM7/25/18
to elixir-l...@googlegroups.com
I do agree about tuple concern and explicitness. After working a long hours it's great to have a little extra safety plus all editors have autocomplete and which also help to save few keystrokes.

Also  Shorthand approach is really good - it's immediately possible to see that a function is being called and thus transformation is more obvious rather than a little more magic in the core.

Cheers.

On Mon, Jul 16, 2018 at 2:20 AM 'Justin Wood' via elixir-lang-core <elixir-l...@googlegroups.com> wrote:
Just an example of a possible solution: we could introduce the shortcut syntax only for structs. Structs cannot be confused with tuples because of the struct name. Structs keys are always atoms, so there is no ambiguity with strings.

I would acutally like if this was done for only structs (and maybe something for records as well, but that is another topic). I think it follows more closely to the three languages that I mentioned earlier in the thread (using it on defined types). I feel like if this were also done for maps, there would be a loss in explicitness.


--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CgIxXdMUkx7LSD4AzBE_KZDElKV8B_fu45NFSdbRbW_c-hF-DkRZPHFRvidoE9FMwhTcmCgvPuyUMJDjF399n20oAwl6xRETkx_MO87NHzs%3D%40protonmail.com.

Amos King

unread,
Jul 25, 2018, 6:04:40 PM7/25/18
to elixir-l...@googlegroups.com
I like the idea of the shorthand syntax as a built-in feature. 

The reading of the code could be slightly more confusing if the syntax is available for maps. I don't think it would be any more confusing than the current language. A sigil can use any brace so it could still be as unclear as %, i.e., %{name, age} vs. ~m{name, age}. I also frequently end up leaving the % off on maps and messing that up with tuples, but I don't think that any of the solutions would make that situation any different.

The feature would be great on maps and structs, but I would be almost as excited about only having the short syntax available for structs. That is an excellent place to start anyway.

Amos King
Owner
Binary Noggin
=======================================================
I welcome VSRE emails. Learn more at http://vsre.info/
=======================================================

On Wed, Jul 25, 2018 at 8:43 AM, Yevhenii Kurtov <yevheni...@gmail.com> wrote:
I do agree about tuple concern and explicitness. After working a long hours it's great to have a little extra safety plus all editors have autocomplete and which also help to save few keystrokes.

Also  Shorthand approach is really good - it's immediately possible to see that a function is being called and thus transformation is more obvious rather than a little more magic in the core.

Cheers.
On Mon, Jul 16, 2018 at 2:20 AM 'Justin Wood' via elixir-lang-core <elixir-lang-core@googlegroups.com> wrote:
Just an example of a possible solution: we could introduce the shortcut syntax only for structs. Structs cannot be confused with tuples because of the struct name. Structs keys are always atoms, so there is no ambiguity with strings.

I would acutally like if this was done for only structs (and maybe something for records as well, but that is another topic). I think it follows more closely to the three languages that I mentioned earlier in the thread (using it on defined types). I feel like if this were also done for maps, there would be a loss in explicitness.


--
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+unsubscribe@googlegroups.com.

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

Yevhenii Kurtov

unread,
Jul 25, 2018, 10:52:12 PM7/25/18
to elixir-lang-core
What's especially beneficial in having it as a part of the core?

On Thursday, July 26, 2018 at 5:04:40 AM UTC+7, Amos King wrote:
I like the idea of the shorthand syntax as a built-in feature. 

The reading of the code could be slightly more confusing if the syntax is available for maps. I don't think it would be any more confusing than the current language. A sigil can use any brace so it could still be as unclear as %, i.e., %{name, age} vs. ~m{name, age}. I also frequently end up leaving the % off on maps and messing that up with tuples, but I don't think that any of the solutions would make that situation any different.

The feature would be great on maps and structs, but I would be almost as excited about only having the short syntax available for structs. That is an excellent place to start anyway.

Amos King
Owner
Binary Noggin
=======================================================
I welcome VSRE emails. Learn more at http://vsre.info/
=======================================================

On Wed, Jul 25, 2018 at 8:43 AM, Yevhenii Kurtov <yevheni...@gmail.com> wrote:
I do agree about tuple concern and explicitness. After working a long hours it's great to have a little extra safety plus all editors have autocomplete and which also help to save few keystrokes.

Also  Shorthand approach is really good - it's immediately possible to see that a function is being called and thus transformation is more obvious rather than a little more magic in the core.

Cheers.
On Mon, Jul 16, 2018 at 2:20 AM 'Justin Wood' via elixir-lang-core <elixir-l...@googlegroups.com> wrote:
Just an example of a possible solution: we could introduce the shortcut syntax only for structs. Structs cannot be confused with tuples because of the struct name. Structs keys are always atoms, so there is no ambiguity with strings.

I would acutally like if this was done for only structs (and maybe something for records as well, but that is another topic). I think it follows more closely to the three languages that I mentioned earlier in the thread (using it on defined types). I feel like if this were also done for maps, there would be a loss in explicitness.


--
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-co...@googlegroups.com.

--
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-co...@googlegroups.com.

Amos King

unread,
Jul 25, 2018, 10:55:37 PM7/25/18
to elixir-l...@googlegroups.com
An officially blessed syntax gets a different level of support and understanding across the entire community. It also keeps new people coming onto projects knowing the syntax and not needing to learn something new because it is a hex package instead of being standard.

Amos King
Owner
Binary Noggin
=======================================================
I welcome VSRE emails. Learn more at http://vsre.info/
=======================================================

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/22d888f8-0d32-4749-a80e-8714ef3bb0ea%40googlegroups.com.

Yevhenii Kurtov

unread,
Jul 26, 2018, 10:47:37 AM7/26/18
to elixir-l...@googlegroups.com
Yeah, but what's the benefit of SHORTHAND syntax? There are no atoms in JS  and thus we have additional bumps on our way to adopting that sugar.
I want to remind that whole store of JS is about adding syntax sugar because language is a mess. All major js libraries prototype, sugar.js, jquery, lodash and others  were solving a problem that doesn't exists in Elixir.
Do we really need this in the core RIGHT NOW?


To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/22d888f8-0d32-4749-a80e-8714ef3bb0ea%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAJr6D4QF5W5Hfj%3D7MYxgMME9MLEqcscz8Aw3VLsgRDkhoK8SyA%40mail.gmail.com.

Dmitry Belyaev

unread,
Jul 27, 2018, 6:43:52 AM7/27/18
to elixir-l...@googlegroups.com, Yevhenii Kurtov
I'm pretty sure it was mentioned before in this thread that some other more serious than JavaScript languages adopted this convenience, and I do remember Rust and Haskell amongst them.

boris kotov

unread,
Jul 27, 2018, 8:04:29 AM7/27/18
to elixir-lang-core
The attention to this feature request, shows, that this would be a very welcome feature, especially for people from other communities.
See, Elixir itself is a language, that combines features and benefits of other languages and technologies.

Syntax is Developer experience and the selling point, that erlang developers take it really serious, because it makes it easy to learn and adapt the language and make the whole erlang ecosystem to the next level.

The benefit of a shorthand syntax is the shorthand syntax, that improves readability.

And this is the point, IMHO if you have to write

~xy(%{foo, bar})wtf = %{foo: "foo", bar: "bar"}

it does make it even uglier.

Again, this is a Proposal, without other "noise" like ~ / : / () / etc.. just the characters we already know from the base Maps syntax: %{}
And ok for the first implementation it can support only atom keys.

%{{foo, bar}} = %{foo: "foo", bar: "bar"}
%{foo: "foo", bar: "bar"} = %{{foo, bar}}



If we could also have some more flexibility, that would be even better:

%{{foo}, bar: named_bar } = %{foo: "foo", bar: "bar"}
# OR
%{bar: named_bar, {foo}} = %{foo: "foo", bar: "bar"}


IMHO the double-brackets syntax makes it really easy to write and read.

Just my 2 cents,

Boris

Yevhenii Kurtov

unread,
Jul 28, 2018, 4:40:31 AM7/28/18
to be.d...@gmail.com, elixir-l...@googlegroups.com
Not a Rust specialist here and according to my limited knowledge shorthand syntax can be only used for the structs initialization, which is fine because struct keys in Elixir can be only atoms AFAIK.

My first  concern is that shorthand syntax should have a natural feeling as well as other parts of the language :)
Another drawback of the shorthand syntax that I saw is that people tends to name variables so the would match map keys of the 3rd party library instead of focusing on the domain they're working in.


Yevhenii Kurtov

unread,
Jul 28, 2018, 5:08:56 AM7/28/18
to be.d...@gmail.com, elixir-l...@googlegroups.com
I guess latest remark is very situational and is not a real concern. Having a good syntax that will look natural for both atom and string keys is the only baseline criteria for this feature from my point of view.

Norbert Melzer

unread,
Jul 28, 2018, 5:23:49 AM7/28/18
to elixir-l...@googlegroups.com, be.d...@gmail.com
I do not like shorthand syntaxes like this, as they mean cognitive overhead for me and possibly even might mean, that I have to use different variable names than what I would originally choose.

Also, especially in elixir, where we strictly differentiate between atom and string keys, we just add another confusion point for beginners, as things do not work as expected. Already said JS programmer might be used to `foo = { "field" : 1 }; {field} = foo` to work, but `foo = %{ "field" => 1 }; %{field} = foo` would brake.

There are already enough pain points for beginners which are related to the string/atom confusion, we do not need to add any more to that.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAJhrTGzRcxmxKxdK%3DYMK83FimHZZzWX7fD-p-gEddvBQ0vvyvw%40mail.gmail.com.

Allen Madsen

unread,
Jul 28, 2018, 10:07:05 AM7/28/18
to elixir-l...@googlegroups.com, be.d...@gmail.com
> I have to use different variable names than what I would originally choose.

I don't think any of the proposals implied this or at least my assumption is that you would be able to use field punning with normal key value pairs.

> Also, especially in elixir, where we strictly differentiate between atom and string keys, we just add another confusion point for beginners, as things do not work as expected.
> Already said JS programmer might be used to `foo = { "field" : 1 }; {field} = foo` to work, but `foo = %{ "field" => 1 }; %{field} = foo` would brake.

This is a good point. However, I think it's an opportunity to provide a good error message. Then the expected syntax becomes a discovery mechanism for the correct way to do it.



To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CA%2BbCVsuU-7Un_3wk1%3Dm4L7rQr9Y6%3DZsSbyZaSBfJnN_r_V0J%3Dg%40mail.gmail.com.

Norbert Melzer

unread,
Jul 28, 2018, 10:46:04 AM7/28/18
to elixir-l...@googlegroups.com, be.d...@gmail.com
Allen Madsen <allen.c...@gmail.com> schrieb am Sa., 28. Juli 2018 um 16:07 Uhr:
> I have to use different variable names than what I would originally choose.

I don't think any of the proposals implied this or at least my assumption is that you would be able to use field punning with normal key value pairs.

Some people might feel forced into this syntax when they want to match on many this way. %{foo, bar: baz}? I do not know… I think most people will either write it out, or juggle with variable names to be able to fully use "simplified" syntax, just because it is possible.

> Also, especially in elixir, where we strictly differentiate between atom and string keys, we just add another confusion point for beginners, as things do not work as expected.
> Already said JS programmer might be used to `foo = { "field" : 1 }; {field} = foo` to work, but `foo = %{ "field" => 1 }; %{field} = foo` would brake.

This is a good point. However, I think it's an opportunity to provide a good error message. Then the expected syntax becomes a discovery mechanism for the correct way to do it.

When do you want to provide a good error message? During compiletime? The compiler does not even know at this point if the right hand side of the match will be a map at all. During runtime? The compiled BEAM code will not even know that it has been generated from the simplified syntax, so you'd need to insert code in the generation process which would do additional checks for string- vs atom keys, which again would mean a massive slow down on this syntax. Also you itroduce an inconsistency, why give a string- vs atom-keys error for simplified syntax, but not for fully written out matches? So we will need to generate the same code for them and therefore slow down about half of elixir in a single go.

 

Allen Madsen

unread,
Jul 28, 2018, 11:40:44 AM7/28/18
to elixir-l...@googlegroups.com, be.d...@gmail.com
On Sat, Jul 28, 2018 at 10:46 AM Norbert Melzer <timm...@gmail.com> wrote:
Allen Madsen <allen.c...@gmail.com> schrieb am Sa., 28. Juli 2018 um 16:07 Uhr:
> I have to use different variable names than what I would originally choose.

I don't think any of the proposals implied this or at least my assumption is that you would be able to use field punning with normal key value pairs.

Some people might feel forced into this syntax when they want to match on many this way. %{foo, bar: baz}? I do not know… I think most people will either write it out, or juggle with variable names to be able to fully use "simplified" syntax, just because it is possible.

This seems like something people here could provide feedback on. For people who have used this feature in other languages, were these things a problem for you?

I can personally say they have not been for the people I work with or me. We use a combination of shorthand and key value pairs. I would say it is common for us to name our variable the same as the key names, but that is because the key name is a good name for the variable. 


> Also, especially in elixir, where we strictly differentiate between atom and string keys, we just add another confusion point for beginners, as things do not work as expected.
> Already said JS programmer might be used to `foo = { "field" : 1 }; {field} = foo` to work, but `foo = %{ "field" => 1 }; %{field} = foo` would brake.

This is a good point. However, I think it's an opportunity to provide a good error message. Then the expected syntax becomes a discovery mechanism for the correct way to do it.

When do you want to provide a good error message? During compiletime? The compiler does not even know at this point if the right hand side of the match will be a map at all. During runtime? The compiled BEAM code will not even know that it has been generated from the simplified syntax, so you'd need to insert code in the generation process which would do additional checks for string- vs atom keys, which again would mean a massive slow down on this syntax. Also you itroduce an inconsistency, why give a string- vs atom-keys error for simplified syntax, but not for fully written out matches? So we will need to generate the same code for them and therefore slow down about half of elixir in a single go.


Yes, it would have to be during runtime for the reason you mention. If this helpful error were always present, it could indeed slow things down. Exception.blame/3 can help with knowing the error, why it happened, and the syntax used. I wouldn't expect this sort of thing to run in production for the reasons you mentioned. However, there is precedence in non-production environments to accept something slower if it improves the developer experience. For example, Phoenix reloads code for you and ExUnit uses Exception.blame/3 for better error messages during tests. Anecdotally, I'll say I never noticed a difference in speed between ExUnit running tests before they added Exception.blame/3 and after. Another possible improvement would be to only do the more expensive exception in places where shorthand was used. However, I agree that I wouldn't make the tradeoff of production runtime performance to show a better error message for someone new to the language.
 

Allen Madsen

unread,
Jul 28, 2018, 12:14:10 PM7/28/18
to elixir-l...@googlegroups.com, be.d...@gmail.com

Yevhenii Kurtov

unread,
Jul 30, 2018, 2:08:50 AM7/30/18
to elixir-l...@googlegroups.com, Dmitry Belyaev
> This is a good point. However, I think it's an opportunity to provide a good error message. Then the expected syntax becomes a discovery mechanism for the correct way to do it.

Sounds like proposal for a  syntax to get error message to discover a right syntax :)

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3Csa%3DsFXptRr%3DTNR0t87ZyUuksUcDXczM8JZqfMz7jy%2B9Q%40mail.gmail.com.

Martin Svalin

unread,
Jul 30, 2018, 4:58:02 AM7/30/18
to elixir-l...@googlegroups.com
I'll add a point that I haven't seen in this thread: there's an established shorthand in Erlang proplists that has a very different meaning.

Proplists are often used in Erlang. They are similar to Keyword lists in Elixir, and have an established shorthand of treating a lone atom as {Atom, true}. This means you'd see [{foo, 1}, bar] in an Erlang proplist, and it would be equivalent to [{foo, 1}, {bar, true}]. This isn't syntax sugar, the data would be different but treated the same.

I worry that a map shorthand along the lines of
%{foo: 1, bar} = some_map
will invoke the expectation that it will be treated as
%{foo: 1, bar: true} = some_map
by someone with an Erlang background. Or, in reverse, setting up the expectation for someone who knows Elixir to misinterpret [{foo, 1}, bar] when reading Erlang.


José Valim

unread,
Jul 30, 2018, 5:43:21 AM7/30/18
to elixir-l...@googlegroups.com
This is another excellent point Martin Svalin.

At this point it has been iterated multiple times that we can't simply translate the shorthand syntax from JavaScript (and others). A hardline has been drawn as well. Unless there are reasonable alternatives, I don't see this feature making it into the language.



José Valim
Skype: jv.ptec
Founder and Director of R&D

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

--
Kind regards,
Dmitry Belyaev

--
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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CA%2BbCVsuU-7Un_3wk1%3Dm4L7rQr9Y6%3DZsSbyZaSBfJnN_r_V0J%3Dg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAAHw6CL%2BUriX7X8v0%3DAhE%3D69phh3B2NqHe2zXZjg6fUGd%3DSkSQ%40mail.gmail.com.

Austin Ziegler

unread,
Jul 30, 2018, 10:07:09 AM7/30/18
to elixir-l...@googlegroups.com
I saw one syntax suggestion that I thought was half-decent, but I’m not convinced that this matters enough to bring it into the language—and I don’t think it conflicts with any other existing syntax.

  austin = %Person{name: "Austin Ziegler", city: "Toronto"}
  %Person(name, city) = person
  other = %Person(name, city)
  override = %Person(name, city: "GTA")

A similar syntax could be used for maps (%() instead of %{}), but I think that’s starting to get a little confusing. I also don’t think it looks as well for update syntax, either:

  %Person(person | name, city: "XYZ")

I worry that it looks too much like a function call, and I also worry that it would lead to confusion about the differences between %X{} and %X(), especially since the %X() form would be able to process the %X{} form without any conflict.

-a

--
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-co...@googlegroups.com.

--
Kind regards,
Dmitry Belyaev

--
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-co...@googlegroups.com.

--
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-co...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-co...@googlegroups.com.

--
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-co...@googlegroups.com.

--
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-co...@googlegroups.com.

--
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-co...@googlegroups.com.

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAAHw6CL%2BUriX7X8v0%3DAhE%3D69phh3B2NqHe2zXZjg6fUGd%3DSkSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2Ba9NHL9NDB4KbvHJoWAjEJwT52ATF7rnbyrt6HELm0MQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


--
Austin Ziegler • halos...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

Louis Pilfold

unread,
Jul 30, 2018, 10:27:40 AM7/30/18
to elixir-l...@googlegroups.com
It's not used, but it's a new syntax, which Elixir tends not to add. What AST would this syntax build?

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAJ4ekQt4Cta_REM5oStm27u7kzkMKBgG7B2%2BN%2ByAd4PeCF68tw%40mail.gmail.com.

Allen Madsen

unread,
Jul 30, 2018, 9:36:56 PM7/30/18
to elixir-l...@googlegroups.com
I've created a rough draft for a proposal that riffs off of a suggestion José made. I haven't finished everything I wanted to cover and some things aren't fully up to date with all the discussions yet. However, it should be complete enough to get the idea across. 


To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFBrE0hi7qtZ1t0fr6A7Bf%2BcHhnxq7vkhY6v3jUzjrwJ1Q%40mail.gmail.com.

Allen Madsen

unread,
Jul 30, 2018, 9:43:48 PM7/30/18
to elixir-l...@googlegroups.com

Chris Keathley

unread,
Jul 31, 2018, 8:47:03 AM7/31/18
to elixir-lang-core
I appreciate the time, energy, and thought that  people have put into this but I have to say I'm strongly against this proposal.

The only benefit of the proposed syntax is brevity and it sacrifices clarity and adds complexity to achieve this brevity. Having magic letters at the end of a map that change how that map is constructed strikes me as pretty beginner hostile. It introduces yet another surprising piece of syntax that you need to hold in your head. It introduces new, non-obvious syntax rules like requiring that your "shorthand" keys come before non-shorthand keys. None of those problems exist with maps as they currently exist at the expense of a little more typing.

If Elixir didn't support both string and atom keys in maps or if we didn't distinguish between the strings and atoms or if the language was different in some other fundamental ways then I'd probably feel differently. But with the Elixir we have today I don't think this proposal is a good fit.

Amos King

unread,
Jul 31, 2018, 9:20:42 AM7/31/18
to elixir-l...@googlegroups.com
What if it only applied to atom keys?

Amos King
Binary Noggin

Ben Wilson

unread,
Jul 31, 2018, 9:42:40 AM7/31/18
to elixir-lang-core
I do think that the forum offers certain benefits as a venue for discussing this over the mailing list. The forum makes it possible to establish certain criterion for post quality, and can keep the discussion more focused. 

Jose has set down some clear issues that a proposal here would need to address, but many people keep posting half baked re-statements of the exact things he's said won't work without any comment addressing his concerns. It's a wildly unproductive way to have this discussion.

Amos King

unread,
Jul 31, 2018, 9:46:47 AM7/31/18
to elixir-l...@googlegroups.com
Let me help make this more productive by adding a link to the forum in question. https://elixirforum.com/t/proposal-add-field-puns-map-shorthand-to-elixir/15452

Amos King
Owner
Binary Noggin
=======================================================
I welcome VSRE emails. Learn more at http://vsre.info/
=======================================================

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/c4675ad3-ca64-4085-a7b3-3acceb2386c2%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages