[eeps] Commit: r49 - eeps/trunk
raimo+eeps@REDACTED
raimo+eeps@REDACTED
Wed Oct 22 09:13:16 CEST 2008
Author: raimo
Date: 2008-10-22 09:13:16 +0200 (Wed, 22 Oct 2008)
New Revision: 49
Added:
eeps/trunk/eep-0024-1.diff
Modified:
eeps/trunk/eep-0000.txt
eeps/trunk/eep-0024.txt
Log:
Modifications and new title to EEP 24
Modified: eeps/trunk/eep-0000.txt
===================================================================
--- eeps/trunk/eep-0000.txt 2008-10-10 07:24:16 UTC (rev 48)
+++ eeps/trunk/eep-0000.txt 2008-10-22 07:13:16 UTC (rev 49)
@@ -46,7 +46,8 @@
S 21 Optional trailing commas for lists and tuples Richard A. O'Keefe
S 22 Range checking for binaries Richard A. O'Keefe
S 23 Allow variables in fun M:F/A Richard A. O'Keefe
- S 24 F/N converts to {F,N} in *all* directives Richard A. O'Keefe
+ S 24 Functions may be named using F/N in all Richard A. O'Keefe
+ module attributes
Key
Added: eeps/trunk/eep-0024-1.diff
Property changes on: eeps/trunk/eep-0024-1.diff
___________________________________________________________________
Name: svn:eol-style
+ native
Modified: eeps/trunk/eep-0024.txt
===================================================================
--- eeps/trunk/eep-0024.txt 2008-10-10 07:24:16 UTC (rev 48)
+++ eeps/trunk/eep-0024.txt 2008-10-22 07:13:16 UTC (rev 49)
@@ -1,5 +1,5 @@
EEP: 24
-Title: F/N converts to {F,N} in *all* directives
+Title: Functions may be named using F/N in all module attributes
Version: $Revision$
Last-Modified: $Date$
Author: Richard A. O'Keefe <ok@REDACTED>
@@ -14,17 +14,19 @@
Abstract
- In directives the form F/N (where F is an atom and N
- is a non-negative integer) should be converted to {F,N}.
+ 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 directive 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.
+ 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
@@ -46,50 +48,87 @@
with
-compile({inline, [
- ukeymerge3_12/13, rukeymerge3_12a/11, rukeymerge3_12b/12,
- ukeymerge3_21/13, rukeymerge3_21a/13, rukeymerge3_21b/12]}).
+ 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]).
+ list_to_set/1,
+ new_set/0,
+ set_to_list/1,
+ subset/2]).
- The improvement in readability is dramatic.
+ 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 directive but
- {new_set,0} in a -deprecated directive, it's the same in all
- directives, making it easier to find directives that mention a
- particular function.
+ 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
- Directives that contain real expressions, such as -record (and,
- if it is accepted, -enum) require a certain amount of care.
- Otherwise, F/N occurrences in -export and -import directives
- _are_ 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.
+ 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 directives 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.
+ 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 code can be affected.
+ 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
- None yet; I really ought to be writing exam questions.
+ 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).
+
+
References
None.
More information about the eeps
mailing list