<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div>Hi there fellow Erlang-developers/users !<br><br></div>I have been using Erlang in a project of mine for a couple of months (4 - 5) now ( coming from a 10 years Java & Python developer-background ) .....after having evaluating/investigating the language and its runtime-system first during some 1 - 2 months before the decision was taken that it address/suits my set of concluded needs very well indeed ( thumbs up for that  :-)   ).<br><br></div>I'm directing these following few issues/questions towards, firstly/primarily, persons on the list which are members of or closely involved/related with the teams behind <a href="http://erlang.org" target="_blank">erlang.org</a> and/or Erlang/OTP at Ericsson.<br><br><br></div>The Erlang VM/architecture, as understood by me, aims/strives for keeping the amounts/occurrences of memory-copy operations to as low as possible. Natural exceptions to that being message-passing between processes .....and I/O - receive/write operations.<br><br></div>My first and primary wondering ( or search for clarification on assumptions ....if you like ) is: ..... do this principle yields from the very first point of local existence ( loaded modules, function-declarations ) ??<br><br></div>If I have say .... a list and a IOlist with elements of deterministic data:<br><br></div>List = "blablabla".<br></div>IOList = [<<"bla">>, <<"bla">>, <<"bla">>].<br><br></div>Will List and IOlist be setup, within the heap-stack of an individual process, as pointers to the original memory-spaces of the lists from the module-load ?? <br><br>.....If these lists are used as included parts in later constructs .......will there then be new pointers setup in the process's heap-stack pointing to the previous ones ??<br><br></div>Does this mechanism ( if it exist as of above ) re-emerge down/up through all the functional/operational levels of the process ( with socket-IO as the entry/exit-point ) ?? <br><br>Does this mechanism ( if it exist as of above ) yields for all Erlang's data/term-types .....or is any of those excluded from it ??<br><br><br></div>If the mechanism exists as assumed so far ....the " in-mutative data-carrier " - property of Erlang becomes obvious/logical understandable for both performance & data-consistency reasons as I perceive the situation in a wider/extended context. An implication become that all concurrent processes within the node shares all originally deterministic data written to memory during module loads !?<br><br></div>As an example ....everything assumed/concluded from this point on would essentially form the whole underlying foundation/reason for why the third-part library / module collection "ErlyDTL" is considered an attractive & high-performing tool for Output/Web- templating. It compiles templates to Erlang modules which then render their outputs from, as I have understood it, special IOlist-constructs holding alternating patterns/sequences of binaries ( fixed text part of original template ) & Funs ( injection/condition/iterator -  statements of original template ). Only the outputs from these Funs then needs to be allocated/written into the heap-stack of the present process. Any further/later inclusive use of the result from the render-operation will, once again, cause new pointers - to - pointers to be setup in the process heap-stack.<br><br><br></div>Under the condition that I have assumed/interpreted/understand this situation correctly ....I think ...indeed ...it should be formalized into a descriptive/introductory piece of information and put in a "front-line" / "early chapter"  place/position within the official Erlang/OTP documentation .... as it truly illustrates something that makes Erlang stand out extensively in relation to most other high-level languages.                   <br><div><div><div><br></div><div>My practical impressions & experience of this language so far have been exclusively rewarding, encouraging & idea-producing for all the "next to come" motivations/objectives in my present time project.<br><br></div><div>Sending my best regards for now / Peter   flexchap at gmail dot com <br></div><div><br><div><div><div><div>               <br></div></div></div></div></div></div></div></div>
</div><br></div>