| Age | Commit message (Collapse) | Author |
|---|
|
For a long time, users have asked for one or more macros that would
return the name and arity of the current function.
We could define a single ?FUNCTION macro that would return
a {Name,Arity} tuple. However, to access just the name or
just the arity for the function, element/2 must be used.
That would limit its usefulness, because element/2 is not
allowed in all contexts.
Therefore, it seems that we will need two macros.
?FUNCTION_NAME that expands to the name of the current function
and ?FUNCTION_ARITY that expands to arity of the current
function.
Converting the function name to a string can be done like this:
f() ->
atom_to_list(?FUNCTION_NAME) ++ "/" ++
integer_to_list(?FUNCTION_ARITY).
f/0 will return "f/0". The BEAM compiler will evaluate the
entire expression at compile-time, so there will not be
any run-time penalty for the function calls.
The implementation is non-trivial because the preprocessor is
run before the parser.
One way to implement the macros would be to replace them with some
placeholder and then let the parser or possibly a later pass replace
the placeholder with correct value. That could potentially slow
down the compiler and cause incompatibilities for parse transforms.
Another way is to let the preprocessor do the whole job. That means
that the preprocessor will have to scan the function head to find
out the name and arity. The scanning of the function head can be
delayed until the first occurrence of a ?FUNCTION_NAME or
?FUNCTION_ARITY.
I have chosen the second way because it seems less likely to cause
weird compatibility problems.
|
|
|
|
|
|
It is harder to remove is_subtype from the parser since the abstract
format does not separate is_subtype from the '::' syntax.
|
|
|
|
erlang:fault no longer exists, so don't mention it in the reference manual.
Also fix minor markup issue in following paragraph.
|
|
|
|
|
|
* richcarl/md5-fixes:
Set module_info md5 for native modules properly
Add module_info entry for native code
Gracefully handle empty md5 field in module_info
Remove 'imports' key from spec of get_module_info()
|
|
|
|
Use the md5 of the native code chunk instead of the Beam code md5.
|
|
|
|
|
|
|
|
Language cleaned up by the technical writers xsipewe and tmanevik
from Combitech. Proofreading and corrections by Hans Bolinder.
|
|
The -dialyzer() attribute can be used for suppressing warnings in a
module by specifying functions or warning options. It can also be used
for requesting warnings in a module.
|
|
|
|
* mururu/typespec-doc-about-function/OTP-12327:
Add infometion about function()
|
|
|
|
|
|
|
|
|
|
There was once a plan to implement support for unicode atoms in OTP
18. This plan has been stopped until further notice, and the
information about this is now removed from the documentation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OTP-11940
* sverk/better-module-info:
Remove obsolete 'imports' entry from module_info/1/2 functions
Add 'module' entry for module_info/0 function for completeness
Add 'md5' entry for module_info/0/1 functions.
|
|
|
|
It previously always returned an empty list
and was documented to be removed.
|
|
as it exist in module_info/1.
|
|
|
|
* egil/maps-doc:
doc: Add Maps example for sequential programming
doc: Mention map expressions and map guards
doc: Add maps to reference manual
edoc: Add map/0 as a new predefined type
doc: Descripe Maps type syntax
doc: Clearify language of user-defined attributes
doc: Document Maps datatype in reference manual
erts: Document map guard functions
erts: Fix is_map/1 spec
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
improper_list(Type1, Type2) has been replaced by
nonempty_improper_list(Type1, Type2).
|
|
* essen/remote-set-cookie/OTP-11637:
set_cookie/2 call needs to be fully qualified
|
|
We can't recommend -on_load() for general use.
|
|
|
|
|
|
* maint:
Correct documentation of predefined types
crypto: Add ticket for 5d8a13bb6a180e0a
|
|
The documentation of predefined types has been corrected
Thanks to Kostis Sagonas.
|
