[erlang-questions] New EEP 45 - FUNCTION macro

[Michael Truog]

On 11/01/2015 05:59 PM, Richard A. O'Keefe wrote:
> On 30/10/2015, at 2:11 am, Björn Gustavsson <bjorn@REDACTED> wrote:
>
>> There is a new EEP 45 that proposes a new
>> FUNCTION macro in the preprocessor.
>>
>> http://www.erlang.org/eeps/eep-0045.html
>> https://github.com/erlang/eep/blob/master/eeps/eep-0045.md
> The problem with ?FUNCTION => {Name,Arity} is that
> obviously sensible things like
> 	fun ?FUNCTION
> don't work.
>
> The problem with ?FUNCTION => Name/Arity would be that
> obviously sensible things like
> 	Name/_Arity = ?FUNCTION
> wouldn't work.
>
> Why not cut the Gordian knot?
> A __FUNCTION__ macro for C makes sense because the arity of
> a C function is not part of its name (but part of its type).
> For Erlang, I respectfully suggest that it makes more sense
> to have *two* macros:
>
> 	?FUNCTION_NAME => the name of the containing function
> 	?FUNCTION_ARITY => the arity of the containing function
>
> and then people can easily write whatever they want.  For example,
>
> f(G, X) when is_function(G, ?FUNCTION_ARITY) -> ...
>
> is a lot clearer than anything involving ?FUNCTION.
>
> The really good thing about defining ?FUNCTION_NAME and
> ?FUNCTION_ARITY is that anyone who *wants* ?FUNCTION is
> then at liberty to
> -define(?FUNCTION, {?FUNCTION_NAME,?FUNCTION_ARITY}).
> if that's what they need.
>
> I did notice that there are definitions of ?FUNCTION_NAME
> and ?FUNCTION_ARITY in the EEP
>
>    *** BUT THEY DOEs NOT WORK IN FUNCTION HEADS **
>
> Nor for that matter will they work after 'fun'.
>
> This makes the claim that ?FUNCTION_NAME and ?FUNCTION_ARITY
> can "easily be defined in terms of FUNCTION" false.
> Given the asymmetry, it is obvious which should be taken as
> basic and which as derived.
>
> Looking at the text,
>    "must be efficient ... slowdown"
> appears to mean macro-expansion time.  It would be good to be
> explicit about that.
>
> As for FUNCTION_STRING, it's not clear why it's
> -define(FUNCTION_STRING, atom_to_list(?FUNCTION_NAME) ++ "/" ++
>            integer_to_list(?FUNCTION_ARITY)).
> rather than
> -define(FUNCTION_STRING,\
>      atom_to_list(?MODULE) ++ ":" ++
>      atom_to_list(?FUNCTION_NAME) ++ "/" ++
>      integer_to_list(?FUNCTION_ARITY)).
>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>

Thank you for adding EEP 45!

I agree that the feature is the most flexible in Erlang when using the
two separate macros: ?FUNCTION_NAME and ?FUNCTION_ARITY .
Using the macros to create the function as data is a good use-case:
F = fun ?FUNCTION_NAME/?FUNCTION_ARITY, ...
which is similar to using the ?MODULE macro to avoid problems
with module name changes during development.