v2) is the default. The old compiler can be chosen by giving a
v1option to the compiler. The compiler will also read default compiler options from the ERL_COMPILER_OPTIONS environment variables.
v2 compiler, which is default, generates smaller and
faster code than the
v1 compiler, but in one case the
compilation can be extremly slow: on pattern matching on long literal
v2 compiler in R6A also compiled huge list
and/or tuple literals slowly. The
v2 compiler in R6B
compiles these literals much faster.
Own Id: OTP-3363
v2versions) have a hard limit on the size of list and tuple literals in Beam modules. This limit 1024, which is the number of registers in the Beam virtual machine. When building a list whose elements are not small integers or atoms, the compiler generates code that builds all list elements from left to right (as the Erlang standard prescribes) saving the built elements in registers. When all elements has been built, the list itself is built. This effectively limits the size of a literal list to 1024 elements.
This limitation will be removed in a future version of the
Note 1: This only applies to list literals in Beam modules,
not to list literals read from data files by
or other means, or lists built dynamically by Erlang code or
BIFs. The only practial limit on the list size is the available
Note 2: Literals list with elements that don't need to be built
beforehand (such as numbers and atoms) can be of any length.
Note 3: The same rules apply to tuples.
Own Id: OTP-3367
io:format("~p\n", [[X]=[a]])', the result of the match expression '
[X]=[a]' should be '
[a]', but in Beam it was '
a'. This all means that multiple patterns in function bodies such as '
[X] = [Y] = [a]' would fail with a badmatch exception in Beam releases before R6. This has been corrected in the new Beam compiler. Incorrect code like '
a = [X] = [a]' which depended on the incorrect behaviour will now fail with a badmatch.
;as separator. This is syntactic sugar which removes the bother of writing the same body after several guards.