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

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

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

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.