[erlang-questions] distinguish proplists vs. lists of proplists

[Richard Carlsson]

On Wed, Sep 16, 2015 at 7:15 AM, Richard A. O'Keefe <ok@REDACTED>
wrote:

>
> On 16/09/2015, at 6:26 am, Drew Varner <drew.varner@REDACTED> wrote:
>
> > A property in a proplist can be an atom or a tuple.
>
> The problem is that the documentation for the proplists
> module says that the elements of a proplist can be ANYTHING.
>
> The documentation is a little confusing.  proplists:get_value/[2,3]
> only pays attention to pairs; other tuples might as well not be there.
>
> Does anyone know *why* the proplists module is so tolerant of
> junk in proplists?  Is it because
>
> get_value(Key, [{Key,Val}|_], _) -> Val;
> get_value(Key, [Key|_],       _) -> true;
> get_value(Key, [_|Ps],  Default) -> get_value(Key, Ps, Default);
> get_value(Key, [],      Default) -> Default.
>
> is the easiest thing to write, or is there a use case for it?
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>


The rationale of the proplists module was to make it easy for a program to
handle options that could have been entered by a human, perhaps directly
from the Erlang shell. (The first real use was in the option handling in
the HiPE compiler.) I wanted it to be possible to use proplists as a
drop-in replacement for most of the local option parsing hacks that were
abundant in existing code - all slighty different. Looking at most modern
code, I'd say that this was achieved - most people seem to be using
proplists now. (Might be changing given that we have maps now - perhaps
proplists should be updated to work on maps as well.) Not all expected uses
of the module were for "options", though, so I didn't name it 'getopt' or
similar, since that would have felt misleading.

Since such lists in existing code often could contain random stuff apart
from obvious key/value pairs or atoms (flags), and I also didn't want to
block someone from using proplists just because they wanted to add some
nonstandard stuff, the proplists module had to be lenient and mainly ignore
anything that it didn't understand. The get_value example was not written
like that because it was easiest, but because there was no obvious
definition of the "value" for a key if the entry is a 3-tuple or larger. So
instead, a user who calls get_value is explicitly asking proplists to
ignore anything but pairs and naked keys, and needs to understand this.

The proplists module was written for flexibility in how one writes the
lists - not for speed (although I did make an effort to make the code as
fast as possible given the constraints). Every now and then, I see someone
benchmarking proplists functions and being surprised that lookups are
slower than lists:keyfind() or similar. If you're having a problem with
proplists performance you're using them wrong. If you need maximum speed,
then extract what you need from the proplists and put the data in a form
that offers faster access times, typically before you enter the main loop
of your program. If you *know* that your lists are strict key/value pairs
and will never be anything else, then you shouldn't be calling the
proplists functions to begin with - just use lists:keyfind(), which is as
fast as it can be.

        /Richard C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150918/5060b24f/attachment.htm>