EEP 24: Functions may be named using F/N in all module attributes #

Abstract #

Programmers will be allowed to name functions using the F/N form (currently restricted to) -export and -import in any module attribute. The parser will convert this to the existing {F,N} form so that downstream tools will be unaffected.

Specification #

In any module attribute the form F/N (where F is an atom and N is a non-negative integer) should be converted to {F,N}, provided that it is not in an expression that would be evaluated.

Other occurrences of X/Y are not addressed by this EEP. In particular, occurrences of X/Y in -record or -enum declarations would be evaluated, so are not affected.

Motivation #

Compare

-compile({inline,
    [{ukeymerge3_12,13}, {ukeymerge3_21,13},
     {rukeymerge3_12a,11}, {rukeymerge3_21a,13},
     {rukeymerge3_12b,12}, {rukeymerge3_21b,12}]}).

-deprecated(
    [{new_set,0},{set_to_list,1},{list_to_set,1},{subset,2}]).

with

-compile({inline, [
    rukeymerge3_12a/11,
    rukeymerge3_12b/12,
    rukeymerge3_21a/13,
    rukeymerge3_21b/12,
    ukeymerge3_12/13,
    ukeymerge3_21/13]}).

-deprecated([
    list_to_set/1,
    new_set/0,
    set_to_list/1,
    subset/2]).

The improvement in readability is noteworthy, especially if authors switch to the Prolog practice of putting one F/N form per line in alphabetic order in such lists.

The improvement in consistency is worth having: it’s no longer a case of new_set/0 in an -export or -import module attribute but {new_set,0} in a -deprecated module attribute, it’s the same in all module attributes, making it easier to find those that mention a particular function.

Rationale #

Module attributes that contain real expressions, such as -record (and, if it is accepted, -enum) require a certain amount of care. I did consider allowing the F/N notation everywhere; after all, an atom cannot be divided by an integer. However, with the fun F/N form available, there are these days very few occasions to refer to a function as {F,N} in an expression.

Otherwise, F/N occurrences in -export and -import attributes are currently converted to tuples (by farity_list), so this is just a small matter of extending the notion elsewhere. I cannot imagine why this wasn’t done years ago.

Backwards Compatibility #

There are currently no attributes where F/N is accepted, is not part of an expression to be evaluated, and does not signify a function, and those where it does signify a function already treat it as an {F,N} tuple.

No existing source code can be affected.

Programs using home-brew front ends instead of the Erlang syntax tools, such as ones that want to preserve white space, comments, and so on, will have to be extended by their maintainers to recognise the new form. It is already the case that {fred,3} may be written in two different ways in Erlang source form: {fred,+3} is also allowed. So such programs already have to cope with multiple source forms with the same abstract form, and this merely adds one more variant.

Programs generating Erlang source code should some day be revised to generate the new form, but since the old form is not being removed and not (in order to preserve the value of recent books) even being deprecated, need not be.

Reference Implementation #

A single clause needs to be added to the normalise/1 function in the parse.yrl file:

%% Name/Arity case
normalise({op,_,'/',{atom,_,F},{integer,_,I}}) when I >= 0 ->
   {F,I};

just before the final clause, which raises an exception. A context diff is provided eep-0024-1.diff.

Copyright #

This document has been placed in the public domain.