cerl module; Core Erlang "forms"

Richard Carlsson <>
Thu Apr 14 23:09:05 CEST 2005


(Note: all of the following is about undocumented internal compiler
details; don't mistake any of it as being officially supported by OTP.)

 wrote:
> ... As far as I looked at the cerl module, this would be possible to 
> achive with Core Erlang, because at least the data constructors allow
>  (at least the documentation states so) to use integers as variable 
> names.

Yes, this is true; the internal representation of a variable name can
be an integer. If the code is pretty-printed, such a variable with
name N will be displayed as _N, which is a legal variable name, and
can be parsed back - but will then become an atom. (Names that already
have the form '_N' are further mangled upon prettyprinting.)

> I have now the following questions: - is the cerl module somehow
> regarded as "stable"; the documentation is no included in the
> "official" documentation available in htmlized form from
> www.erlang.org, so I assume it is not!?

I can't speak for Ericsson, but being the author, I can say that the
interface has not gone through any significant changes in a long time,
and it seems unlikely (to me) that it will do so in the future. (The
last big change was the stabilization and documentation of binary-syntax
in Core Erlang, see http://www.it.uu.se/research/group/hipe/cerl/ for
the latest version of the specification.)

> - are variables internally always handled as atoms, or get atoms 
> generated in later compilation steps? get the variable identifiers 
> converted to atoms from integers?

What I described above is only true from the Core Erlang level down;
the later stages treat integer-named variables in the same way, and do
not convert them (as far as I know - does Björn have a comment?), until
all variables are replaced with Beam abstract machine registers. Stages
before Core Erlang probably do not like integers.

Most of the older parts of the compiler take the quick-and-dirty
approach to unique variable generation and create atoms consisting
of an ordinal number prefixed with some abbreviation for the particular
compiler stage, such as 'pre42' or 'ker17'.  The undocumented compiler
module 'rec_env' has support for generating new random variable names
(integer or otherwise) that are not in the current environment - this
is used in particular in the Core Erlang inliner, and might be of help
to you. Happy hacking!

	/Richard




More information about the erlang-questions mailing list