[eeps] Commit: r49 - eeps/trunk

raimo+eeps <>
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 <>
@@ -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