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

[Jonathan Coveney]

I love the thoughtfulness of this listserv.

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]

[1] where the devil is, so they say

Thanks for the responses!
Jon

2012/5/7 Thomas Lindgren <thomasl_erlang@REDACTED>

>
>
>
>
> ----- 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120508/2b1fd90a/attachment.htm>