Association list utilities Lassi Kortela (10 Jun 2020 08:24 UTC)
Re: Association list utilities Marc Nieper-Wißkirchen (10 Jun 2020 08:30 UTC)
Re: Association list utilities Lassi Kortela (10 Jun 2020 08:49 UTC)
Re: Association list utilities Marc Nieper-Wißkirchen (10 Jun 2020 09:29 UTC)
Re: Association list utilities Lassi Kortela (10 Jun 2020 09:59 UTC)
Re: Association list utilities Marc Nieper-Wißkirchen (10 Jun 2020 10:09 UTC)
Re: Association list utilities Lassi Kortela (10 Jun 2020 10:37 UTC)
Re: Association list utilities Arne Babenhauserheide (10 Jun 2020 10:33 UTC)

Re: Association list utilities Lassi Kortela 10 Jun 2020 09:59 UTC

>      > Using two-element lists instead of pairs means that another pair
>      > has to be needlessly allocated for each entry in the association list.
>
> We have already alists and plists. Maybe, it makes sense to coin another
> term, say, xlists where the entries are proper lists

Interesting idea.

Plists have a different structure from alists (though they support
equivalent operations and take the same number of pairs for storage).

Xlists however are a special case of alist where the cdr of each
association pair happens to be a list. Hence it may be possible to fold
xlist operations naturally into the alist API without having to talk
about a new kind of list.

It would also be possible to have `xplists` :) If you store a list as
the value of each plist entry.

You can also store a list as the value of each hash-table entry, which I
have done countless times. It's very useful. I presume SRFI 146 mappings
could have lists as values.

Hence I'd suggest starting from the fact that any key->value collection
(John would call them dictionaries) can have lists for values.

Alists (and plists) can have duplicate keys. That raises the additional
concern of what to do about duplicate keys whose values are lists.
Should we only take the list corresponding to the first key, or should
we `append` the lists from all entries with that key?

> While alists will be more efficient for simple key-value pairings,
> xlists will have advantage that they allow multiple values to be stored
> for a key:

Indeed.

Another advantage is that consing dots are really not readable to people
who are not Lisp diehards. Even I don't like them asthetically and find
them inconvenient when editing :)

Xlists are something a Python or JavaScript programmer for example can
comprehend immediately, since they look just like Python lists, just
with parentheses instead of square brackets or curly braces. This is
especially important when using S-expressions for data files which are
meant to be comprehensible to Lisp casuals or people from other language
communities.