aboutsummaryrefslogtreecommitdiffstats
path: root/system/doc/getting_started
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2015-10-26 12:02:40 +0100
committerBjörn Gustavsson <[email protected]>2016-02-17 16:56:04 +0100
commit1604b874828e8ef992c8e17e06e7af20a0f1574b (patch)
tree0a5a595d169f4108ef77e907d3a671efb04fa702 /system/doc/getting_started
parent5f571ca95a0cd22dcd050c43dbf111aeece89fd7 (diff)
downloadotp-1604b874828e8ef992c8e17e06e7af20a0f1574b.tar.gz
otp-1604b874828e8ef992c8e17e06e7af20a0f1574b.tar.bz2
otp-1604b874828e8ef992c8e17e06e7af20a0f1574b.zip
Implement ?FUNCTION_NAME and ?FUNCTION_ARITY macros
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.
Diffstat (limited to 'system/doc/getting_started')
0 files changed, 0 insertions, 0 deletions