Skip to content


Subversion checkout URL

You can clone with
Download ZIP
tag: svn-import
Fetching contributors…

Cannot retrieve contributors at this time

151 lines (102 sloc) 4.342 kb
EEP: 24
Title: Functions may be named using F/N in all module attributes
Version: $Revision$
Last-Modified: $Date$
Author: Richard A. O'Keefe <>
Status: Draft
Type: Standards Track
Erlang-Version: R12B-4
Content-Type: text/plain
Created: 22-Sep-2008
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.
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.
[{ukeymerge3_12,13}, {ukeymerge3_21,13},
{rukeymerge3_12a,11}, {rukeymerge3_21a,13},
{rukeymerge3_12b,12}, {rukeymerge3_21b,12}]}).
-compile({inline, [
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.
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:
%% Name/Arity case
normalise({op,_,'/',{atom,_,F},{integer,_,I}}) when I >= 0 ->
just before the final clause, which raises an exception.
A context diff is provided (eep-0024-1.diff).
This document has been placed in the public domain.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
Jump to Line
Something went wrong with that request. Please try again.