[erlang-questions] Can people please stop misinterpreting what I wrote?

[Ulf Wiger]

Michael Turner wrote:
> 
> I *asked* what, exactly, in the problem that
> James' code is intended to solve, couldn't be solved in
 > classic Erlang style with data compression?

Going back to the OP's actual question is a novel concept,
but not nearly as fun as redefining the question into what
suits your own ambition, and going from there. :)

Having re-read what James initially asked for, it seemed
to me as a pretty clever poor-man's version for answering
the question "are these two objects not just equal, but
the /same/ object?". This cannot be done today in Erlang.
If it could, it would be possible to write your own
sharing-preserving term_to_binary().

The suggestion from James was that an access structure
library could fake that by telling the caller "this is
the object I have", and the caller could use that instead,
and thereby achieving a higher degree of sharing.

(To address your question then, compression seems to not
address this problem, as the idea of having clever helper
functions to help make use of sharing implies extremely
lightweight semantics. Often, making use of sharing not
only reduces memory consumption, but also improves
performance, and James' suggesion really doesn't carry
any overhead in terms of execution time - but compression
definitely does.)

The same effect could be achieved by calling gb_trees:find()
first, and then perhaps calling insert, but I assume James
would prefer to achieve this effect without having to access
the tree twice?

But given that an API change is asked for in a set of core
libraries (since the APIs of the different access structures
are harmonized, it wouldn't be just gb_trees), it begs the
question - do we want to promote the use of sharing (inside
terms)? If yes, what does that imply? The big, ugly problem
that needs to be solved then is the one where you can in fact
kill the entire VM if a term that aggressively uses sharing
happens to get passed in a message (which can happen e.g.
if the process crashes and there are linked processes).

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com