[erlang-questions] EEP 45: New macros for function name and arity

[Björn Gustavsson]

Thanks for the corrections and suggestions.

I will incorporate them into the next draft
which I will probably prepare at the
beginning of next week.

/Björn


On Thu, Nov 12, 2015 at 4:04 AM, Richard A. O'Keefe <ok@REDACTED> wrote:
> The current draft
>
> * defines FUNCTION_STRING (in Examples)
>
> * has a section saying why FUNCTION_STRING
>   doesn't exist.
>
> I suggest that the section title should be
> "Why do I have to define FUNCTION_STRING myself?"
> and that the most important reason is that there
> are *two* reasonable definitions
>
> -define(FUNCTION_STRING,
>    atom_to_list(?FUNCTION_NAME) ++ "/" ++
>    integer_to_list(?FUNCTION_ARITY)).
>
> and
>
> -define(FUNCTION_STRING,
>    ?MODULE_STRING ++ ":" ++
>    atom_to_list(?FUNCTION_NAME) ++ "/" ++
>    integer_to_list(?FUNCTION_ARITY)).
>
> and that it's up to you to pick the one you need.
> That section starts with
>
> There already exist MODULE and MODULE_STRING macros,
> so why no MODULE_STRING macro?
>           ^^^^^^^^^^^^^
>
> where the second MODULE_STRING should be FUNCTION_STRING.
>
> It would be nice if the Examples section included
>
> self_ref(Data, Handler) ->
>     ...
>     Handler(fun ?FUNCTION_NAME/?FUNCTION_ARITY, Data)
>     ...
>
> Now the message I am replying to says that
> -define(FOO, foo).
> ?FOO(?FOO) -> ?FOO.
> is *not* a 'form that starts with an atom followed
> by a left parenthesis'.  But the EEP specifically
> says
> The following is also legal:
>
> -define(A, a).
> ?A(?FUNCTION_NAME) -> ok.
>
> Perhaps the simplest model is just to say that
> ?FUNCTION_NAME (and of course ?FUNCTION_ARITY)
> may not begin any form.
>
>
>
>
>
>



-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB