Recent changes to Precedence

WikiPage Precedence modified by David A. Wheeler

David A. Wheeler — Wed, 05 Sep 2012 23:35:46 -0000

--- v43
+++ v44
@@ -14,7 +14,7 @@
 
 The new "math" ruleset is as follows:
 
-* All even-numbered parameters must be operator symbols, there must be an odd number of parameters, and there must be at least three parameters (it must be *strictly infix*).
+* All even-numbered parameters must be operator symbols, there must be an odd number of parameters, and there must be at least five parameters (it must be *strictly infix*).
 * The operators supported, in precedence order (high to low), are:
     - Subscript/down-arrow: sub {Unicode: ↓, ⇓}
     - Exponentiation/Superscript/up-arrow: \*\*, ^, sup {Unicode: ↑, ⇑} (right-associative)

WikiPage Precedence modified by David A. Wheeler

David A. Wheeler — Sun, 26 Aug 2012 20:01:23 -0000

--- v42
+++ v43
@@ -109,4 +109,4 @@
 *   If you have an operator registration systems, where you register the precedence of operations, then you end up with bugs if the definition isn't read first. Even worse, you have trouble combining code when the operators have different precedence.
 *   But if you don't have a registration system, that means you have to have pre-set fixed rules for operators.  Which at least avoids those problems, *and* is consistent with what most other languages do (most languages have fixed precedence systems).  At that point, it's hard to argue that it should be a short list, and you end up with complex systems like this.
 
-I think the important point from this page is that this is proof that accepting curly-infix now does *not* prevent support for precedence in the future.
+I think the important point from this page is that this is proof that accepting curly-infix now does *not* prevent support for precedence in the future.  It also explains why we did *NOT* propose it :-).

WikiPage Precedence modified by David A. Wheeler

David A. Wheeler — Sun, 26 Aug 2012 20:00:33 -0000

--- v41
+++ v42
@@ -106,7 +106,7 @@
 
 Oh, I'm not *recommending* this precedence system.  Indeed, this is a great example of why precedence systems haven't been widely accepted in Lisps; they get ugly as soon as you look into the details:
 
-*   If you have an operator registration systems, where you register the precedence of operations, then you end up with bugs if the definition isn't read first, and you have trouble combining code when the operators have different precedence.
+*   If you have an operator registration systems, where you register the precedence of operations, then you end up with bugs if the definition isn't read first. Even worse, you have trouble combining code when the operators have different precedence.
 *   But if you don't have a registration system, that means you have to have pre-set fixed rules for operators.  Which at least avoids those problems, *and* is consistent with what most other languages do (most languages have fixed precedence systems).  At that point, it's hard to argue that it should be a short list, and you end up with complex systems like this.
 
 I think the important point from this page is that this is proof that accepting curly-infix now does *not* prevent support for precedence in the future.

WikiPage Precedence modified by David A. Wheeler

David A. Wheeler — Sun, 26 Aug 2012 19:59:51 -0000

--- v40
+++ v41
@@ -105,7 +105,8 @@
 ## Comments by dwheeler
 
 Oh, I'm not *recommending* this precedence system.  Indeed, this is a great example of why precedence systems haven't been widely accepted in Lisps; they get ugly as soon as you look into the details:
-* If you have an operator registration systems, where you register the precedence of operations, then you end up with bugs if the definition isn't read first, and you have trouble combining code when the operators have different precedence.
-* But if you don't have a registration system, that means you have to have pre-set fixed rules for operators.  Which at least avoids those problems, *and* is consistent with what most other languages do (most languages have fixed precedence systems).  At that point, it's hard to argue that it should be a short list, and you end up with complex systems like this.
+
+*   If you have an operator registration systems, where you register the precedence of operations, then you end up with bugs if the definition isn't read first, and you have trouble combining code when the operators have different precedence.
+*   But if you don't have a registration system, that means you have to have pre-set fixed rules for operators.  Which at least avoids those problems, *and* is consistent with what most other languages do (most languages have fixed precedence systems).  At that point, it's hard to argue that it should be a short list, and you end up with complex systems like this.
 
 I think the important point from this page is that this is proof that accepting curly-infix now does *not* prevent support for precedence in the future.

WikiPage Precedence modified by David A. Wheeler

David A. Wheeler — Sun, 26 Aug 2012 19:56:14 -0000

--- v39
+++ v40
@@ -6,7 +6,7 @@
 
 That said, it'd be possible to add precedence support, either to this or a future version of curly-infix, as long as the list of operators is a *fixed* definition that is *independent* of a particular Lisp (e.g., focused on "pure" math functions). The key is that, in a Lisp, any precedence rules must be absolutely fixed.  Remember, the reader is used for program data, not just for programs, which often mixed together.  In many cases they're split into multiple files that are loaded, and reloaded, at relatively arbitrary times relative to each other.  If you have to manipulate a table, or declare precedence for operators before reading them, the effort of managing the table becomes too complex (it'd be better to use nfx, which *more* flexible than a table while requiring fewer built-in mechanisms).  Remember, a Lisp program may manage several different languages and meta-levels at once, all mixed together; precedence variation in this circumstance is too confusing.   In particular, if you have to declare operator precedence, it becomes unworkable; there's often no way to be sure that the declaration was read and applied before the operator is seen.  And it becomes a true nightmare if the precedence level definitions disagree (a scoped operator like nfx can deal with this; a Lisp reader is a poor substitute).
 
-If support for precedence is important for acceptance of curly-infix, we *could* add precedence.  So, if precedence is important for its acceptance, or in some future version precedence is considered important, here's a modified curly-infix rule to provide support for precedence (this was the best that David A. Wheeler could come up with).
+If support for precedence is important for acceptance of curly-infix, we *could* add precedence.  So, if precedence is important for its acceptance, or in some future version precedence is considered important, here's a modified curly-infix rule to provide support for precedence (this was the best that David A. Wheeler could come up with).  Perhaps most important, this is proof that accepting curly-infix now does *not* prevent support for precedence in the future.
 
 In this version, you still have to specially call unary functions, e.g.: (- x), -(x), or -{x}... you can't just say {- - x}, since that looks like you're subtracting "x" from "-".  In compensation, this rule is extremely flexible - you can use a large number of different symbols for operators.  I think that "you must specially call all unary functions" is an easy rule to remember and apply.
 
@@ -101,3 +101,11 @@
 My final reaction is "NO".
 
 My final reaction is "NO"
+
+## Comments by dwheeler
+
+Oh, I'm not *recommending* this precedence system.  Indeed, this is a great example of why precedence systems haven't been widely accepted in Lisps; they get ugly as soon as you look into the details:
+* If you have an operator registration systems, where you register the precedence of operations, then you end up with bugs if the definition isn't read first, and you have trouble combining code when the operators have different precedence.
+* But if you don't have a registration system, that means you have to have pre-set fixed rules for operators.  Which at least avoids those problems, *and* is consistent with what most other languages do (most languages have fixed precedence systems).  At that point, it's hard to argue that it should be a short list, and you end up with complex systems like this.
+
+I think the important point from this page is that this is proof that accepting curly-infix now does *not* prevent support for precedence in the future.

WikiPage Precedence modified by David A. Wheeler

David A. Wheeler — Sun, 26 Aug 2012 19:48:09 -0000

--- v38
+++ v39
@@ -27,8 +27,8 @@
         - Unranged:  =, ==, !=, \<>, =/=, eq..., in, is {Unicode: ≠, ≈, ≅}
     - Logical conjunction: and {Unicode: ∩, ∧}
     - Logical/exclusive disjunction: or, xor, eor {Unicode: ∪, ∨, ⊕}
-    - Implication/Right Arrows/Doubled arrows: ->, =>,  <->, <=>, -->, ==>, <-->, <==> {Unicode: ↔, ⇔, ←, ⇐, →, ⇒}
-    - Definition/Assignment/Left arrow: <-, <--, <==, :=, ::=  {Unicode: ≡} (right-associative)
+    - Implication/Right Arrows/Doubled arrows: ->, =>,  <->, <=>, -->, ==>, <-->, <==> {Unicode: ↔, ⇔, →, ⇒}
+    - Definition/Assignment/Left arrow: <-, <--, <==, :=, ::=  {Unicode: ≡  ←, ⇐} (right-associative)
 * Other operators are re-compared by removing from its symbol all "-" surrounded by alphanumerics, all alphanumerics, and then all other characters not in an operator above (so "char<=?" is accepted as "<=").  If there's no match, it does not meet the "math" ruleset.
 *  When the same operator is repeated, the operator simply gains another operand, so {a + b + c * d} is the "+" operator applied to three operands: a, b, and (* c d).
 * If different *ranged comparison* operators are used in sequence, they are joined by "and" as follows:  {left compare1 middle compare2 right...} maps to (and (compare1 left middle) (compare2 middle right) ...).

WikiPage Precedence modified by David A. Wheeler

David A. Wheeler — Sun, 26 Aug 2012 19:46:44 -0000

--- v37
+++ v38
@@ -27,8 +27,8 @@
         - Unranged:  =, ==, !=, \<>, =/=, eq..., in, is {Unicode: ≠, ≈, ≅}
     - Logical conjunction: and {Unicode: ∩, ∧}
     - Logical/exclusive disjunction: or, xor, eor {Unicode: ∪, ∨, ⊕}
-    - Implication/Arrows: ->, =>, <-, <->, <=>, -->, ==>, <--, <==, <-->, <==> {Unicode: ↔, ⇔, ←, ⇐, →, ⇒}
-    - Definition/Assignment: :=, ::=  {Unicode: ≡} (right-associative)
+    - Implication/Right Arrows/Doubled arrows: ->, =>,  <->, <=>, -->, ==>, <-->, <==> {Unicode: ↔, ⇔, ←, ⇐, →, ⇒}
+    - Definition/Assignment/Left arrow: <-, <--, <==, :=, ::=  {Unicode: ≡} (right-associative)
 * Other operators are re-compared by removing from its symbol all "-" surrounded by alphanumerics, all alphanumerics, and then all other characters not in an operator above (so "char<=?" is accepted as "<=").  If there's no match, it does not meet the "math" ruleset.
 *  When the same operator is repeated, the operator simply gains another operand, so {a + b + c * d} is the "+" operator applied to three operands: a, b, and (* c d).
 * If different *ranged comparison* operators are used in sequence, they are joined by "and" as follows:  {left compare1 middle compare2 right...} maps to (and (compare1 left middle) (compare2 middle right) ...).

WikiPage Precedence modified by Alan Manuel Gloria

Alan Manuel Gloria — Thu, 23 Aug 2012 01:18:17 -0000

--- v36
+++ v37
@@ -92,10 +92,12 @@
 
 ## Comments by almkglor
 
-My first reaction was "".
+My first reaction was "\".
 
-My second reaction was "".
+My second reaction was "\".
 
-My third reaction was "This  is too complex."
+My third reaction was "This \ is too complex."
+
+My final reaction is "NO".
 
 My final reaction is "NO"

WikiPage Precedence modified by Alan Manuel Gloria

Alan Manuel Gloria — Thu, 23 Aug 2012 01:17:39 -0000

--- v35
+++ v36
@@ -89,3 +89,13 @@
 Thus, I propose to continue with the much simpler rule we have, and then switch to a precedence system if we get too much pushback from the simpler rule.  Or alternatively, make it clear that perhaps someday there could be a more sophisticated curly-infix system, but that it's more important to get basic functionality today.
 
 Comments welcome.
+
+## Comments by almkglor
+
+My first reaction was "".
+
+My second reaction was "".
+
+My third reaction was "This  is too complex."
+
+My final reaction is "NO"

WikiPage Precedence modified by David A. Wheeler

David A. Wheeler — Sun, 19 Aug 2012 00:01:23 -0000

--- v34
+++ v35
@@ -8,11 +8,9 @@
 
 If support for precedence is important for acceptance of curly-infix, we *could* add precedence.  So, if precedence is important for its acceptance, or in some future version precedence is considered important, here's a modified curly-infix rule to provide support for precedence (this was the best that David A. Wheeler could come up with).
 
-The "precedence" form of the curly-infix would be as follows (note the new middle rule):
+In this version, you still have to specially call unary functions, e.g.: (- x), -(x), or -{x}... you can't just say {- - x}, since that looks like you're subtracting "x" from "-".  In compensation, this rule is extremely flexible - you can use a large number of different symbols for operators.  I think that "you must specially call all unary functions" is an easy rule to remember and apply.
 
-1.  If a list is a simple curly-infix list, map to (even-parameter odd-parameters) as now.
-2.  Otherwise, if a list meets the "math" ruleset requirements, use its mapping (see below).
-3.  Otherwise, return the list with the "nfx" symbol added to the front as now.
+The "precedence" form of the curly-infix would add a new rule: "If a curly-infix list isn't simple, if the list meets the "math" ruleset requirements, use its mapping (see below).  Otherwise, return the list with the "nfx" symbol added to the front (as is done now)."
 
 The new "math" ruleset is as follows: