<html><head></head><body bgcolor="#FFFFFF"><blockquote type="cite"><div><br><font class="Apple-style-span" color="#000000"><br></font><span>So perhaps the right approach is to do a kickstarter to fund someone writing a deep dive Erlang/OTP internals book? </span><br><span>Complexity: roughly the level of writing a Linux kernel book, at a quick guess. Perhaps a bit easier.</span><br><span></span><br></div></blockquote><div><br></div><div>That would be a vital spot on every erlang programmer's bookshelf for sure.</div><br><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite"><span> Another argument might be that BEAM should be specified in detail in order </span><br></blockquote></blockquote><blockquote type="cite"><span>to be a suitable binary format for distribution, </span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span> which is essentially what the JVM instruction set has become.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I suggested many years ago that Erlang should take a leaf out of Kistler's</span><br></blockquote><blockquote type="cite"><span>book (or PhD thesis). The "Juice" system for Oberon compiled source </span><br></blockquote><blockquote type="cite"><span>files</span><br></blockquote><blockquote type="cite"><span>to abstract syntax trees, then cleverly compressed the ASTs and used them</span><br></blockquote><blockquote type="cite"><span>as the binary distribution form. They came in smaller than .class files</span><br></blockquote><blockquote type="cite"><span>and had no presuppositions about the target hardware (not even primitive</span><br></blockquote><blockquote type="cite"><span>size and alignment if I recall correctly). The cost of decompressing and</span><br></blockquote><blockquote type="cite"><span>generating native code was low, to the point where it was faster to</span><br></blockquote><blockquote type="cite"><span>dynamically load Juice files than their equivalent of .so/.dll files, and</span><br></blockquote><blockquote type="cite"><span>the generated code actually ran faster because the code generator knew</span><br></blockquote><blockquote type="cite"><span>more about the environment of the target, including existing code. (I</span><br></blockquote><blockquote type="cite"><span>don't know if the Juice runtime did cross-module inlining, but it would</span><br></blockquote><blockquote type="cite"><span>have been possible.)</span><br></blockquote><span></span><br><span></span><br><span>Not a bad idea.</span><br><span></span><br><span>Best regards,</span><br><span>Thomas</span><br><span></span><br><span>_______________________________________________</span><br><span>erlang-questions mailing list</span><br><span><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></span><br><span><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a></span><br></div></blockquote></body></html>