[erlang-questions] Special syntax for dictionaries
Thu May 6 11:44:18 CEST 2010
I see that there are four questions we are discussing here. So our
decision tree would be:
#1. Do we need a special syntax for dictionaries?
Thing that lead me to wish a special syntax for dictionaries was
JSON/YAML documents, where keys are strings (or even integers stored
as strings). JSON is a good example, so I will use it to illustrate
where dictionaries can be useful.
When to use:
* You don't know for sure *how many* keys there will be.
JSON can be sent to you through RESTful interface with a lot of fake
keys, and you don't want to store them as atoms in the global atom
* You don't know for sure *what* keys there will be.
Sometimes key you have is a combination of different nested keys. In
Redis database it's common to use keys like "user/name". Some subkeys
can be integers. There can be something behind the string
representation, so you may want to parse the key. Atoms aren't
strings, so what you can do on it is limited.
* You want to have pattern matching
Manipulation such a JSON-documents without pattern matching is a pain.
With dictionaries you shouldn't be restricted to atoms as keys. If
your keys are known for your program, you probably want something more
suitable for structures like frames/structs.
#1.1 If we need syntax for dictionaries, what syntax to use?
#2. Do we need first class replacement (frames/structs) for records?
Yes, because records have some well known runtime restrictions.
#2.1 If we need frames/structs, what syntax to use?
So dictionaries are more "dynamic", when frames/struct are more "static".
> Remember what the frames proposal is FOR.
> It is NOT a "dictionaries" or "hash tables" proposal or anything
> even remotely like that.
Actually my previous message wasn't about "let's use term() for keys
in frames". I really would like to have both of them implemented. I
wrote the first message because I felt the lack of syntax for
> It's a "clean replacement for the -record kluge" proposal.
I would be happy to have first-class replacement for records in Erlang.
> To that end, _fast_ construction and matching and _low_ memory
> requirements are "must haves". The report explains this in some
I couldn't find your report. Could you post the link here?
> You might want to think about reducing the size of those JSON
> keys in order to reduce transport costs.
Actually, the size of my JSON keys is small. I'm just a bit afraid of
using atoms, because atoms aren't garbage collected and atoms aren't
that good for string processing (regular expressions, parsing,
validation) just because atoms aren't strings.
Abstract patterns, structs and frames:
Here's hoping we get frames or structs in 2009!:
Fix up records so that record are first-class citizens and not just
syntax saccharine for tuples?
More information about the erlang-questions