Why are Keyword lists restricted to [{:atom, _}]?

[Wiebe-Marten Wijnja]

I recently worked on some code where I wanted to store {key, value}-pairs and newer values entered for the same key should shadow older values.

So, I tried using Keyword lists.

However, the keys in my list were not atoms but Strings -- they contain properties that users might enter, and therefore it is unsafe to work with atoms directly (as they are never garbage collected, at some point they can and will make your system run out of memory).

But then this turned out not to work! Keyword requires keys to always be an atom.

This choice has been made deliberately in the past (the documentation clearly states it, using the access protocol for keywords will throw a descriptive error message, etc.), 

but it is unclear why.

Above use case seems relatively general to me.

For instance, OptionsParser.parse/1 always returns a Keyword list with atoms right now, and suffers from the atom-garbage-problem because of it. 

(OptionsParser.parse/2 allows you to specify what switches should be allowed, but this is not appropriate for all use cases)

Why is the current behaviour as it is right now?

[José Valim]

A long time ago we were used to have ListDict and, as expected, using a list as a dictionary is a very bad idea as it performs very poorly. So the reason keywords only allow atoms is to put emphasis on their use cases of being a very specific data structure for passing options and not a general purpose one.

So if you are trying to use it as a key-value store and arrived to the conclusion you cannot, it is doing its job. :)

PS: I believe OptionsParser does not leak atoms as we check those accordingly. If it does, please open up a bug report.

José Valim

www.plataformatec.com.br

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/69fe6eeb-19a1-4edf-8908-ddfe70734b60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aleksei Magusev]

In fact, OptionsParser was leaking atoms, but it was fixed some time ago and included in v1.4 (commit https://github.com/elixir-lang/elixir/commit/8c68ab6f2e60e891e2efef25943533fb5b515093).

On Sunday, January 8, 2017 at 9:09:34 PM UTC+1, José Valim wrote:

A long time ago we were used to have ListDict and, as expected, using a list as a dictionary is a very bad idea as it performs very poorly. So the reason keywords only allow atoms is to put emphasis on their use cases of being a very specific data structure for passing options and not a general purpose one.

So if you are trying to use it as a key-value store and arrived to the conclusion you cannot, it is doing its job. :)

PS: I believe OptionsParser does not leak atoms as we check those accordingly. If it does, please open up a bug report.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

On Sun, Jan 8, 2017 at 8:08 PM, Wiebe-Marten Wijnja <w.m.w...@panache-it.com> wrote:

I recently worked on some code where I wanted to store {key, value}-pairs and newer values entered for the same key should shadow older values.

So, I tried using Keyword lists.

However, the keys in my list were not atoms but Strings -- they contain properties that users might enter, and therefore it is unsafe to work with atoms directly (as they are never garbage collected, at some point they can and will make your system run out of memory).

But then this turned out not to work! Keyword requires keys to always be an atom.

This choice has been made deliberately in the past (the documentation clearly states it, using the access protocol for keywords will throw a descriptive error message, etc.), 

but it is unclear why.

Above use case seems relatively general to me.

For instance, OptionsParser.parse/1 always returns a Keyword list with atoms right now, and suffers from the atom-garbage-problem because of it. 

(OptionsParser.parse/2 allows you to specify what switches should be allowed, but this is not appropriate for all use cases)

Why is the current behaviour as it is right now?

--
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.