I love the thoughtfulness of this listserv.<div><br></div><div>I think a tutorial would be invaluable. I think the sorts of people who get into erlang may be like me... some functional background, a lot of non-functional background, you see erlang and want to get a sense of how the opcodes (and by extension the internals) work. You can trawl the source (and I will), but I definitely think that if someone were up to it, the community would be well served by a tutorial on the implementation details.[1]</div>
<div><br></div><div>[1] where the devil is, so they say</div><div><br></div><div>Thanks for the responses!</div><div>Jon<br><br><div class="gmail_quote">2012/5/7 Thomas Lindgren <span dir="ltr"><<a href="mailto:thomasl_erlang@yahoo.com" target="_blank">thomasl_erlang@yahoo.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
<br>
<br>
----- Original Message -----<br>
> From: Michael Turner <<a href="mailto:michael.eugene.turner@gmail.com">michael.eugene.turner@gmail.com</a>><br>
> To: Thomas Lindgren <<a href="mailto:thomasl_erlang@yahoo.com">thomasl_erlang@yahoo.com</a>><br>
> Cc: Jonathan Coveney <<a href="mailto:jcoveney@gmail.com">jcoveney@gmail.com</a>>; "<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>" <<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>><br>

> Sent: Monday, May 7, 2012 11:27 AM<br>
> Subject: Re: [erlang-questions] Is there a good source for documentation on BEAM?<br>
><br>
>& quot;Actually, I don't think such docs are all _that_ crucial -- who<br>
<div class="im">> really needs to know, except a small number of VM implementors?"<br>
><br>
> Aren't Erlang's chances of greater mindshare improved by making it<br>
> easier to become a VM implementor? I doubt very much that Java would<br>
> be where it is today had it not been for clear VM specification.<br>
> That's not to say that Erlang should follow in all of Java's<br>
> footsteps, even if it could. But I have to say I was a boggled to<br>
> learn that you can't find out what the VM opcodes mean without reading<br>
> the source (and maybe not even then, if the source contains bugs<br>
> vis-a-vis some idealized machine model.)<br>
<br>
<br>
</div>Well, we should ask why we need them.<br>
<br>
There has been a substantial number of non-BEAM Erlang implementations already, so I'm<br>
not convinced detailed BEAM docs is the key property* to spread Erlang. <br>
Indeed, requiring detailed docs of every change of BEAM seems likely to slow innovation down instead.<br>
<br>
If the motive is education, I think someone interested in compilers and virtual machine architectures<br>
would have little trouble with BEAM as such. In a real sense, BEAM is just a vehicle to express compiler optimizations for a<br>
restricted part of ERTS (the sequential execution part, basically). The interesting choices and optimizations are found by examining<br>
the whole implementation. But again, a tutorial could be useful.<br>
<br>
Another argument might be that BEAM should be specified in detail in order to be a suitable binary format for distribution, <br>
which is essentially what the JVM instruction set has become. (The commercial implementations convert it into internal<br>
formats and optimize the hell out of those.) My druthers would in that case be to define something less detailed <br>
and less changeable to serve in this role. <br>
<br>
Okay, that's all I can come up with.<br>
<br>
(* I'd prefer to have the marketing muscle of Sun instead!)<br>
<br>
Best regards,<br>
Thomas<br>
<br>
</blockquote></div><br></div>