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.

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.

Progams 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: