Is it ever a good idea to use association lists instead of records?

Question

Would any experienced Erlang programmers out there ever recommend association lists over records?

One case might be where two (or more) nodes on different machines are exchanging messages. We want to be able to upgrade the software on each machine independently. Some upgrades may involve adding a field to one (or more) of the messages being sent. It seems like using a record as the message would mean you'd always have to do the upgrade on both machines in lock step so that the extra field didn't cause the receiver to ignore the record. Whereas if you used something like an association list (which still has a "record-like" API), the not-yet-upgraded receiver would still receive the message successfully and just ignore the new field. I realize this isn't always the desired behavior, but often it is. Also, assume the messages are fairly small so the lookup time doesn't matter.

Assuming the above makes some sense, I have the following additional questions:

• Is there a standard (or widely used) library for alists? Some trivial googling didn't turn up anything.
• Are there other cases where you would use an association list (or something like it)?

Answer 1

Note that lists:keysearch/3 is pretty much "assq".

Answer 2

For small amount of keys you can use lists aka proplists for bigger you should use dict. In both cases biggest disadvantage is that you can't use pattern match in way as used for records. There is also speed penalty but it is in most cases irrelevant.

Answer 3

You have basically three choices:

1. Use Records
2. Use Association Lists (proplists)
3. Use Combination

I use records where the likelihood of changing it is very low. That way I get the pattern matching and speed up that I want.

I use proplists where I need hashtable like functionality. I get flexibility at the expense of pattern matching and speed.

And sometimes I use both. A record with one field that is a proplist. That way I can pattern match on a portion of it and yet have flexibility where I need it.

All three choices have different trade-offs so you basically just have to evaluate your particular needs and make a choice. It may take some prototyping and playing around to figure out which trade-offs make sense and which features you absolutely must have.