[erlang-questions] Is there a good source for documentation on BEAM?

[Thomas Lindgren]

----- Original Message -----
> From: Michael Turner <michael.eugene.turner@REDACTED>
> To: Thomas Lindgren <thomasl_erlang@REDACTED>
> Cc: Jonathan Coveney <jcoveney@REDACTED>; "erlang-questions@REDACTED" <erlang-questions@REDACTED>
> Sent: Monday, May 7, 2012 11:27 AM
> Subject: Re: [erlang-questions] Is there a good source for documentation on BEAM?
> 
>& quot;Actually, I don't think such docs are all _that_ crucial -- who
> really needs to know, except a small number of VM implementors?"
> 
> Aren't Erlang's chances of greater mindshare improved by making it
> easier to become a VM implementor? I doubt very much that Java would
> be where it is today had it not been for clear VM specification.
> That's not to say that Erlang should follow in all of Java's
> footsteps, even if it could. But I have to say I was a boggled to
> learn that you can't find out what the VM opcodes mean without reading
> the source (and maybe not even then, if the source contains bugs
> vis-a-vis some idealized machine model.)


Well, we should ask why we need them.

There has been a substantial number of non-BEAM Erlang implementations already, so I'm
not convinced detailed BEAM docs is the key property* to spread Erlang. 
Indeed, requiring detailed docs of every change of BEAM seems likely to slow innovation down instead.

If the motive is education, I think someone interested in compilers and virtual machine architectures
would have little trouble with BEAM as such. In a real sense, BEAM is just a vehicle to express compiler optimizations for a
restricted part of ERTS (the sequential execution part, basically). The interesting choices and optimizations are found by examining
the whole implementation. But again, a tutorial could be useful.

Another argument might be that BEAM should be specified in detail in order to be a suitable binary format for distribution, 
which is essentially what the JVM instruction set has become. (The commercial implementations convert it into internal
formats and optimize the hell out of those.) My druthers would in that case be to define something less detailed 
and less changeable to serve in this role. 

Okay, that's all I can come up with.

(* I'd prefer to have the marketing muscle of Sun instead!)

Best regards,
Thomas