[eeps] Commit: r63 - eeps/trunk

raimo+eeps@REDACTED raimo+eeps@REDACTED
Fri Feb 27 12:27:43 CET 2009


Author: raimo
Date: 2009-02-27 12:27:43 +0100 (Fri, 27 Feb 2009)
New Revision: 63

Modified:
   eeps/trunk/eep-0030.txt
Log:
Updated revsion of EEP 30 changing from operators to functions


Modified: eeps/trunk/eep-0030.txt
===================================================================
--- eeps/trunk/eep-0030.txt	2009-02-26 09:38:27 UTC (rev 62)
+++ eeps/trunk/eep-0030.txt	2009-02-27 11:27:43 UTC (rev 63)
@@ -2,7 +2,7 @@
 Title: Maximum and Minimum
 Version: $Revision$
 Last-Modified: $Date$
-Author: Richard A. O'Keefe < ok (at) cs (dot) otago (dot) ac (dot) nz >
+Author: Richard A. O'Keefe <ok@REDACTED>
 Status: Draft
 Type: Standards Track
 Erlang-Version: R12B-4
@@ -14,28 +14,31 @@
 
 Abstract
 
-    Add maximum and minimum operators.
+    Add maximum and minimum core functions.
 
 
 
 Specification
 
     Currently the Erlang language has no built-in support for
-    the maximum and minimum operations.  So we add
+    the maximum and minimum operations.  So we add new functions
 
-    /\  with the same precedence and associativity as band
-    \/  with the same precedence and associativity as bor
-
-    E1 /\ E2 has the same effects and value as
+    erlang:min(E1, E2)  with the same effects and value as
 	(T1 = E1, T2 = E2, if T1 > T2 -> T2 ; true -> T1 end)
-    E1 \/ E2 has the same effects and value as
+
+    erlang:max(E1, E2)  with the same effects and value as
 	(T1 = E1, T2 = E2, if T1 > T2 -> T1 ; true -> T2 end)
+
     except that we expect them to be implemented using single VM
     instructions, and we expect HiPE to use conditional moves on
     machines that have them.
 
+    The erlang: module prefix on max/2 (respectively min/2) can
+    be omitted if and only if there is no locally defind max/2
+    (respectively min/2).
 
 
+
 Motivation
 
     Maximum and minimum are extremely useful operations.
@@ -93,42 +96,41 @@
 
     Function or operator?
 
-    The operations /\ and \/ defined in lattice theory are very
-    nice operations indeed.  They are commutative, associative,
-    and idempotent.  So having to choose between max(X,max(Y,Z))
-    and max(max(X,Y),Z) is an unjustifiable burden on the
-    programmer.  Fortran's answer (and Lisp's) is to allow any
-    number of arguments to the max and min functions.  That is
-    not something that suits Erlang.
+    I believe that there are excellent reasons to use the standard
+    /\ and \/ symbols from lattice theory.  However, discussion in
+    the EEPs mailing list showed that the community was divided
+    into
+      - people who were familiar with the operators
+      - people who insisted that they were only Boolean operators
+      - people who didn't get them at all because they weren't C.
 
-    Another argument against a function is the risk of clashing
-    with the very many existing definitions of max and min.
+    The ready availability of the operations as a standard part of
+    the language is much more important than what they are called,
+    so the second draft of this EEP switched to built in functions
+    in order to increase acceptance.
 
-    Should an operator be alphabetic or symbolic?
-    Adding new alphabetic operators creates problems for people
-    who are already using the atom in question.
-    However, it may be justifiable when there is no widely
-    accepted notation for the operation that can be readily
-    expressed in widely used character sets.
+    The argument which finally settled it for me was the
+    internationalisation one:  Japanese programmers may be using
+    keyboards where \ means or screens where \ displays as Yen,
+    so /\ and \/ just won't work for them.
 
-    Maximum and minimum DO have very well established mathematical
-    symbols.  In ASCII, those symbols look like /\ and \/.
-    In fact, /\ and \/ are *precisely* what the backslash character
-    in ASCII exists for; it had no other original purpose.
+    We cannot use max and min as operators because the compiler
+    will not let you use a symbol as both an operator and a function
+    name, and there are lots and lots of uses of max and min as
+    function names.  That's precisely the problem we're trying to
+    address here.  So they have to be function names.
 
-    If Erlang were C, the (sole originally intended) use of the
-    backslash here would be a lexical problem.  But it isn't.
-    Backslash is used for character escapes in Erlang, and using
-    it in operators in no way conflicts with that.
+    There is no great difficulty in adding new functions to the
+    erlang: module.
 
-    The remaining question is the precedence level.
-    `band' is the specialisation of /\ to the bit string lattice.
-    `and'  is the specialisation of /\ to the false < true lattice.
-    Those operators have the same precedence, so /\ should agree.
-    `bor'  is the specialisation of \/ to the bit string lattice.
-    `or'   is the specialisation of \/ to the false < true lattice.
-    Those operators have the same precedence, so \/ should agree.
+    I don't want to write the erlang: prefix here.  There is
+    nothing new in making the erlang: prefix for some functions
+    optional either.
 
+    What we want is for existing modules with their own definitions
+    of max/2 and/or min/2 to remain legal, and then to be upgraded
+    simply by removing the redundant definitions.
+
     Imagine that you want to find the bounding box for a set
     of 2D points.  (This is adapted from code in Wings3D.)
 
@@ -151,20 +153,17 @@
     With maximum and minimum operators, this becomes
 
     bounding_box([{X,Y}|Pts], Xlo,Xhi, Ylo,Yhi) ->
-        bounding_box(Pts, X/\Xlo, X\/Xhi, Y/\Ylo, Y\/Yhi);
+        bounding_box(Pts, min(X,Xlo), max(X,Xhi),
+			  min(Y,Ylo), max(Y,Yhi));
     bounding_box([], Xlo,Xhi, Ylo,Yhi) ->
 	{{Xlo,Ylo}, {Xhi,Yhi}}.
 
-    There is a cultural clash with Prolog, which used /\ and
-    \/ for bitwise and and bitwise or respectively.  Since
-    Erlang has never used these operators for that purpose,
-    the clash always existed anyway.
 
 
-
 Backwards Compatibility
 
-    No issues.
+    No issues.  Where a module already has max/2 or min/2,
+    the erlang: prefix is required to get the new function.
 
 
 




More information about the eeps mailing list