<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 10, 2016 at 1:16 PM,  <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":135" class="a3s aXjCH m155d4860c64cf8ab">No, I tell a lie.  The *best* thing is to NOT add a new low-level<br>
data structure to Erlang.  Mixing data structures between languages<br>
with different memory management strategies is for people who like<br>
pain too much.</div></blockquote></div><br>The only time where this is somewhat acceptable is the case where the underlying data structure can be embedded in the host language. In Erlang's case, this demands that the underlying data structure be persistent rather than ephemeral[0]. Some times, you can write a data structure which has (locally) benign effects, but where the interface to that data structure is safe from the outside. In that case, you may rewrite the data structure due to demands of efficiency in your program.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In general though, it tend to be a better long-term stategy to implement such a data structure in Erlang, *before* dropping to C. That way, you have a reference implementation you can use as a test case for verifying the correctness of the low-level embedded efficient datastructure. Also, as ok@ writes, the GC interface between different languages is often treacherous waters[1].</div><div class="gmail_extra"><br></div><div class="gmail_extra">[0] Roughly: that you can refer to older versions of the data structure in the code. This is true for any Erlang data structure, except the process dictionary and ETS tables. In particular, any destructive update is forbidden.<br><br>[1] OCaml recently added "ephemerons" to their language for this very reason. They allow the usual "weak" references with an elegant extra set of rules, which allows more elegant implementations of e.g., LRU caches. Having those in the language often allows the GC to interplay with foreign data in a nicer way.<br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">J.</div>
</div></div>