<div dir="ltr"><div class="gmail_extra">If you do want to keep a full history of inserts, couldn't you use a dict(K, [V])? Sure, you'd have to write a few functions, since dict:append/3 doesn't have the desired semantics, but such functions are straightforward to write.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">prepend(K, V, D) -></div><div class="gmail_extra">    dict:update(K, fun (Vs) -> [V | Vs] end, [V], D).</div><div class="gmail_extra"><br></div><div class="gmail_extra">
<br><div class="gmail_quote">On Sun, Jun 22, 2014 at 11:06 AM, Jay Nelson <span dir="ltr"><<a href="mailto:jay@duomark.com" target="_blank">jay@duomark.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I’m implementing a library using dictionaries and I’ve noticed that all the<br>
dictionary alternatives use imperative-style initialization semantics. Proplists were<br>
introduced to allow efficient shadowing of environments and defaults.<br>
Pushing a value on the front of a proplist makes the first value encountered<br>
be the current value. You can then pop contexts and reveal the older values<br>
efficiently in a functional programming style.<br>
<br>
Dictionaries use hash-like semantics of last value wins in an imperative<br>
assignment that clobbers old values (and loses them forever) thus making<br>
them non-functional and non-persistent. I assume initialization of dictionaries<br>
are kept imperative for consistency / efficiency, but it makes the two styles<br>
of initialization incompatible (but keeps the internal semantics of each<br>
datatype consistent).<br>
<br>
The recommended technique for maps is to set a default dictionary and<br>
then the shadowing dictionary and merge them. I guess this leads to a<br>
functional style of a stack of maps for shadowing contexts, but this approach<br>
is only recommended as overcoming default initialization. In recent code,<br>
I’ve had to use different semantics for defaulted values vs user-specified<br>
values and having a dictionary meant I couldn’t tell whether the current<br>
value was an implicit default or an explicit choice after the initialization<br>
phase had completed.<br>
<br>
Do others build proplists and then reverse them when initializing a dictionary?<br>
(This seems very imperative, having to maintain your own data versions:<br>
proplist and dictionary init list, especially if you want shadowing semantics<br>
and need to go back to the source context and initialize subsequent dictionaries).<br>
<br>
Or do you maintain a stack of dictionaries and do a cascading search until<br>
a value is found? This approach allows context labeling and thus you could<br>
know if a value was explicit or implicitly defaulted.<br>
<br>
Or do you just change to an imperative style for your code when you start<br>
thinking with dictionaries (or have you not noticed the difference)?<br>
<br>
My new library is supposed to allow selection of implementation without<br>
change to the higher-level logic. I suppose I am going to have to provide<br>
‘proplist (functional)’ and ‘last wins (imperative)’ options for initialization<br>
of the underlying implementation (and do proper initialization in all cases).<br>
<br>
My current approach is to stick with a functional style of programming<br>
and use proplist semantics on initialization of my object wrappers around<br>
dictionaries (dict, orddict, vbisect; maps in future; possibly will add<br>
proplists and records as options as well, and I suppose arrays could<br>
be used). The current overhead expense is that I have to scan the init<br>
list while constructing the dictionary doing lookups to see if a value is<br>
already set and skip it in the case of an earlier definition (I also do this<br>
because I sometimes need to validate the datatypes to ensure that<br>
constructed dictionaries use legal types on all input — I could switch<br>
to a faster initialization in cases where datatype doesn’t matter by<br>
reversing the list, assuming the list size is never ginormous).<br>
<br>
jay<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div></div>