Recent changes to SRFI-Curly

WikiPage SRFI-Curly modified by David A. Wheeler

David A. Wheeler — Wed, 22 Aug 2012 11:06:22 -0000

--- v41
+++ v42
@@ -1,4 +1,10 @@
-Here's a proposed submission for the Scheme SRFI process per http://srfi.schemers.org/srfi-process.html
+DO NOT EDIT THIS FILE
+=====================
+
+The current draft of the SRFI-curly-infix file is in the git repository, please make changes there.
+
+
+Below is the original draft submission for the Scheme SRFI process per http://srfi.schemers.org/srfi-process.html
 
 ---------------------------

WikiPage SRFI-Curly modified by David A. Wheeler

David A. Wheeler — Tue, 14 Aug 2012 23:15:23 -0000

--- v40
+++ v41
@@ -51,6 +51,8 @@
 
 If a reader implements this SRFI, we would like it to *always* be enabled.  However, we provide a "enable-curly-infix" function so that implementors can make it optional, or to switch from whatever was their previous interpretation.  By having a standard mechanism for enabling it, we hope will encourage adoption.  The enabling mechanism doesn't use any module system; some implementations won't have one (or at least not a standard one).  Users should invoke "(enable-curly-infix)" before using curly-infix lists.  The "curly-infix-read" function allows reading external curly-infix data, even if the implementation doesn't implement it by default.  The "transform-not-simple-infix" function is suggested so that some future SRFI author can define some infix precedence system (if a future community decides it wants one), but it is not required.
 
+There's no explicit "disable-curly-infix".  There's no reason to disable it within this SRFI, and if some other action changes the meaning of braces, it would be that other action that disables it.
+
 There is no requirement that writers (e.g., "write") write out curly-infix expressions.  They may choose to do so, e.g., for lists of length 3-6 whose car is the symbol "and", symbol "or", or a punctuation-only symbol.  However, it would probably be wise to wait until many implementations can handle c-expressions.
 
 This is an unusually simple mechanism, but like much of any Lisp-based language, its power comes from its simplicity.
@@ -89,7 +91,7 @@
 Reference implementation
 ========================
 
-The implementation below is trivial and portable, however, Scheme provides no standard mechanism to override {...} in the reader to *call* it.  Thus, implementations will typically have a modified reader that hooks into {...}.  We'd like implementations to always do this, but to comply with the SRFI this must at least be active after (enable-curly-infix) is called.
+The implementation below is portable, with the exception that Scheme provides no standard mechanism to override {...} in its built-in reader.  Thus, implementations will typically have a modified reader that detects "{", starts reading a list until its matching "}", and then calls process-curly defined below.  We recommend that implementations *always* do this, but an implementation must at least activate this behavior when (enable-curly-infix) is called.
 
 This reference implementation is SRFI type 2: "A mostly-portable solution that uses some kind of hooks provided in some Scheme interpreter/compiler. In this case, a detailed specification of the hooks must be included so that the SRFI is self-contained."

WikiPage SRFI-Curly modified by David A. Wheeler

David A. Wheeler — Tue, 14 Aug 2012 23:08:04 -0000

--- v39
+++ v40
@@ -81,7 +81,7 @@
 
 * Implementations must provide the function (curly-infix-read . port) that can read a c-expression.
 * Implementations must provide the function (enable-curly-infix), which enables this capability in the default reader ("read" and "get-datum"), the reader used in the REPL, and the reader used by "load", whether or not it was previously enabled.   However, we encourage systems to *always* have this capability enabled, even if enable-curly-infix is not called.
-* Implementations may provide an overrideable function (transform-not-simple-infix lyst), which takes the list as read in that was determined to not be a simple curly-infix list; it then returns a transformation of it (e.g., a list with "nfx" in front).
+* Implementations may provide an overrideable function (transform-not-simple-infix lyst) that can be "set!"; this receives the non-simple curly-infix list; and returns a transformation of it (e.g., a list with "nfx" in front).
 
 Note that, by definition, this SRFI modifies lexical syntax.

WikiPage SRFI-Curly modified by David A. Wheeler

David A. Wheeler — Tue, 14 Aug 2012 23:06:53 -0000

--- v38
+++ v39
@@ -28,7 +28,7 @@
 Abstract
 ========
 
-Lisp-based languages, like Scheme, are almost the only programming languages in modern use that do not support infix notation.  Adding infix support to Scheme would eliminate a common complaint by developers who currently choose to use other languages.  Scheme currently reserves {...} "for possible future extensions to the language".  We propose that {...} be used to support "curly-infix" notation as a reader abbreviation, just as 'x is an abbreviation for (quote x).  If the curly-infix list represents a single operator with operands, it is immediately transformed to (operator operands); otherwise, it becomes (nfx original-parameters) for later precedence processing.
+Lisp-based languages, like Scheme, are almost the only programming languages in modern use that do not support infix notation.  Adding infix support to Scheme would eliminate a common complaint by developers who currently choose to use other languages.  Scheme currently reserves {...} "for possible future extensions to the language".  We propose that {...} be used to support "curly-infix" notation as a reader abbreviation, just as 'x is an abbreviation for (quote x).  If the curly-infix list represents a single operator with operands, the reader maps it to (operator operands); otherwise, it becomes (nfx original-parameters).
 
 Rationale
 =========
@@ -49,21 +49,49 @@
 
 Curly-infix requires that infix operators be delimited (e.g., by spaces).  This is consistent with Lisp history; operators are always delimited in traditional s-expressions (typically by left parentheses on the left, and space on the right).  It's also impractical to do otherwise; most Lisps, including Scheme, allow and predefine symbols that include characters (like "-") that are typically used for infix operators.  Many developers will put space around infix operators even in languages that don't require them, so syntactically requiring them is no burden.  In short, it is difficult to allow infix operators without delimiters, and the visual results are the same as many real-world uses in other languages, so the result appears quite customary to typical software developers.
 
-If a reader implements this SRFI, we would like it to *always* be enabled.  However, we provide a "enable-curly-infix" function so that implementors can make it optional, or to switch from whatever was their previous interpretation.  By having a standard mechanism for enabling it, we hope will encourage adoption.  Users should invoke "(enable-curly-infix)" before using curly-infix lists.
+If a reader implements this SRFI, we would like it to *always* be enabled.  However, we provide a "enable-curly-infix" function so that implementors can make it optional, or to switch from whatever was their previous interpretation.  By having a standard mechanism for enabling it, we hope will encourage adoption.  The enabling mechanism doesn't use any module system; some implementations won't have one (or at least not a standard one).  Users should invoke "(enable-curly-infix)" before using curly-infix lists.  The "curly-infix-read" function allows reading external curly-infix data, even if the implementation doesn't implement it by default.  The "transform-not-simple-infix" function is suggested so that some future SRFI author can define some infix precedence system (if a future community decides it wants one), but it is not required.
 
-There is no requirement that writers write out curly-infix expressions.  They may choose to do so.  However, it would probably be wise for them to wait until many implementations can handle them.
+There is no requirement that writers (e.g., "write") write out curly-infix expressions.  They may choose to do so, e.g., for lists of length 3-6 whose car is the symbol "and", symbol "or", or a punctuation-only symbol.  However, it would probably be wise to wait until many implementations can handle c-expressions.
 
 This is an unusually simple mechanism, but like much of any Lisp-based language, its power comes from its simplicity.
 
 Note that this is the first of three tiers developed by the "readable" project.  We intend to later submit two more SRFIs, for defining the other two tiers that build on top of curly-infix-expressions.
 
+
+Specification
+=============
+
+"Curly-infix-expressions" (c-expressions) are s-expressions with an additional notation: The curly-infix list.  A curly-infix list is syntactically identical to a normal list, except it is surrounded by curly braces instead of by parentheses.  Once a curly-infix list is read, it is mapped differently than a regular list, depending on whether or not it is simple.  A simple curly-infix list is a curly-infix list that represents a single infix operation (it has an odd number of parameters, at least three parameters, and all even parameters are "eq?" symbols); a simple curly-infix list is mapped by the reader into a list with the even parameter followed by the odd parameters.  A non-simple curly-infix list is mapped to the list with the symbol "nfx" added to its front.
+
+A "curly-infix-expression" datum reader is a reader that can correctly read curly-infix-expressions.
+
+Here are some examples of c-expressions:
+
+*   {n <= 2} maps to (<= n 2)
+*   {2 * 3 * 4} maps to (* 2 3 4)
+*   {a * {b + c}} maps to (* a (+ b c))
+*   {q + r * s} maps to (nfx q + r * s)
+*   {x eqv? 'a} maps to (eqv? x 'a)
+*   {(- a) / b} maps to (/ (- a) b)
+*   {(f a b) + (g h)} maps to (+ (f a b) (g h))
+*   '{a + (f b) + x} maps to '(+ a (f b) x)
+*   {{a > 0} and {b >= 1}} maps to (and (> a 0) (>= b 1))
+
+Functions:
+
+* Implementations must provide the function (curly-infix-read . port) that can read a c-expression.
+* Implementations must provide the function (enable-curly-infix), which enables this capability in the default reader ("read" and "get-datum"), the reader used in the REPL, and the reader used by "load", whether or not it was previously enabled.   However, we encourage systems to *always* have this capability enabled, even if enable-curly-infix is not called.
+* Implementations may provide an overrideable function (transform-not-simple-infix lyst), which takes the list as read in that was determined to not be a simple curly-infix list; it then returns a transformation of it (e.g., a list with "nfx" in front).
+
+Note that, by definition, this SRFI modifies lexical syntax.
+
+
 Reference implementation
 ========================
 
+The implementation below is trivial and portable, however, Scheme provides no standard mechanism to override {...} in the reader to *call* it.  Thus, implementations will typically have a modified reader that hooks into {...}.  We'd like implementations to always do this, but to comply with the SRFI this must at least be active after (enable-curly-infix) is called.
 
-The implementation below is trivial and portable, except that Scheme provides no standard mechanism to override {...} in the reader.  Thus, implementations will typically have a modified reader that hooks into {...}.  We'd like implementations to always do this, but to comply with the SRFI this must at least be active after (enable-curly-infix) is called.
-
-Note that this reference implementation is type 2: "A mostly-portable solution that uses some kind of hooks provided in some Scheme interpreter/compiler. In this case, a detailed specification of the hooks must be included so that the SRFI is self-contained."
+This reference implementation is SRFI type 2: "A mostly-portable solution that uses some kind of hooks provided in some Scheme interpreter/compiler. In this case, a detailed specification of the hooks must be included so that the SRFI is self-contained."
 
 ~~~~
 :::scheme
@@ -116,32 +144,6 @@
 ~~~~
 
 
-
-Specification
-=============
-
-"Curly-infix-expressions" (c-expressions) are s-expressions with an additional notation: The curly-infix list.  A curly-infix list is syntactically identical to a normal list, except it is surrounded by curly braces instead of by parentheses.  Once a curly-infix list is read, it is mapped differently than a regular list, depending on whether or not it is simple.  A simple curly-infix list is a curly-infix list that represents a single infix operation (it has an odd number of parameters, at least three parameters, and all even parameters are "eq?" symbols); a simple curly-infix list is mapped by the reader into a list with the even parameter followed by the odd parameters.  A non-simple curly-infix list is mapped to the list with the symbol "nfx" added to its front.
-
-A "curly-infix-expression" datum reader is a reader that can correctly read curly-infix-expressions.
-
-Here are some examples:
-
-*   {n <= 2} maps to (<= n 2)
-*   {2 * 3 * 4} maps to (* 2 3 4)
-*   {a * {b + c}} maps to (* a (+ b c))
-*   {q + r * s} maps to (nfx q + r * s)
-*   {x eqv? 'a} maps to (eqv? x 'a)
-*   {(- a) / b} maps to (/ (- a) b)
-*   {(f a b) + (g h)} maps to (+ (f a b) (g h))
-*   '{a + (f b) + x} maps to '(+ a (f b) x)
-*   {{a > 0} and {b >= 1}} maps to (and (> a 0) (>= b 1))
-
-Implementations must provide the function (curly-infix-read . port) to implement this functionality.  In addition, the function (enable-curly-infix) must enable this capability in the default reader ("read" and "get-datum"), the reader used in the REPL, and the reader used by "load".   However, we encourage systems to *always* have this capability enabled, even if enable-curly-infix is not called.
-
-Note that, by definition, this SRFI modifies lexical syntax.
-
-
-
 References
 ==========

WikiPage SRFI-Curly modified by David A. Wheeler

David A. Wheeler — Tue, 14 Aug 2012 20:49:48 -0000

--- v37
+++ v38
@@ -15,10 +15,10 @@
 Status
 ======
 
-This is not yet an official SRFI.  To see an explanation of each status that a SRFI can hold, see here.
 
-To provide input on this SRFI, please  mail to <srfi minus ??? at srfi dot schemers dot org>.  See  instructions here to subscribe to the list.  You can access previous messages via  the archive of the mailing list.
+To provide input on this SRFI, please  mail to <srfi minus ??? at srfi dot schemers dot org>.  See  instructions here to subscribe to the list.  You can access previous messages via  the archive of the mailing list.
 
 Related SRFIs
 =============
@@ -37,7 +37,7 @@
 
 Scheme currently reserves {...} "for possible future extensions to the language".  We propose that {...} be used to support "curly-infix" notation as a reader abbreviation, just as 'x is an abbreviation for (quote x).
 
-This proposal is an extremely *simple* and *straightforward* technique for supporting infix notation.  There is no complex precedence system, all other Scheme capabilities (including macros) work unchanged, and Scheme remains general and homoiconic. Curly-infix expressions are just a convenient abbreviation for infix notation, just like 'x maps to (quote x). 
+This proposal is an extremely *simple* and *straightforward* technique for supporting infix notation.  There is no complex precedence system, all other Scheme capabilities (including macros) work unchanged, and Scheme remains general and homoiconic. Curly-infix expressions are just a convenient reader abbreviation for infix notation, just like 'x is an abbreviation of (quote x). 
 
 Many previous systems have implemented "infix" systems as a named macro or function (often "nfx" meaning infix).  This looks ugly, and it does the wrong thing - the resulting list always has "nfx" at the beginning, not the actual infix operator, so this approach can interfere with quoting, macros, and other capabilities.  Many of these past systems also created a whole new notation which simultaneously lost Lisp's abilities for quoting, quasiquoting, and so on.  This proposal avoids these problems.
 
@@ -50,6 +50,8 @@
 Curly-infix requires that infix operators be delimited (e.g., by spaces).  This is consistent with Lisp history; operators are always delimited in traditional s-expressions (typically by left parentheses on the left, and space on the right).  It's also impractical to do otherwise; most Lisps, including Scheme, allow and predefine symbols that include characters (like "-") that are typically used for infix operators.  Many developers will put space around infix operators even in languages that don't require them, so syntactically requiring them is no burden.  In short, it is difficult to allow infix operators without delimiters, and the visual results are the same as many real-world uses in other languages, so the result appears quite customary to typical software developers.
 
 If a reader implements this SRFI, we would like it to *always* be enabled.  However, we provide a "enable-curly-infix" function so that implementors can make it optional, or to switch from whatever was their previous interpretation.  By having a standard mechanism for enabling it, we hope will encourage adoption.  Users should invoke "(enable-curly-infix)" before using curly-infix lists.
+
+There is no requirement that writers write out curly-infix expressions.  They may choose to do so.  However, it would probably be wise for them to wait until many implementations can handle them.
 
 This is an unusually simple mechanism, but like much of any Lisp-based language, its power comes from its simplicity.

WikiPage SRFI-Curly modified by David A. Wheeler

David A. Wheeler — Tue, 14 Aug 2012 20:44:20 -0000

--- v36
+++ v37
@@ -59,7 +59,9 @@
 ========================
 
 
-The actual implementation is trivial, except that Scheme provides no standard mechanism to override {...} in the reader.  Thus, modify the reader to hook into {...}.  We'd like implementations to always do this, but at least always do it when (enable-curly-infix) is called.
+The implementation below is trivial and portable, except that Scheme provides no standard mechanism to override {...} in the reader.  Thus, implementations will typically have a modified reader that hooks into {...}.  We'd like implementations to always do this, but to comply with the SRFI this must at least be active after (enable-curly-infix) is called.
+
+Note that this reference implementation is type 2: "A mostly-portable solution that uses some kind of hooks provided in some Scheme interpreter/compiler. In this case, a detailed specification of the hooks must be included so that the SRFI is self-contained."
 
 ~~~~
 :::scheme

WikiPage SRFI-Curly modified by David A. Wheeler

David A. Wheeler — Tue, 14 Aug 2012 19:24:47 -0000

--- v35
+++ v36
@@ -62,7 +62,7 @@
 The actual implementation is trivial, except that Scheme provides no standard mechanism to override {...} in the reader.  Thus, modify the reader to hook into {...}.  We'd like implementations to always do this, but at least always do it when (enable-curly-infix) is called.
 
 ~~~~
-#!/usr/bin/guile
+:::scheme
     ; Return true if lyst has an even # of parameters, and the (alternating)
     ; first parameters are "op".  Used to determine if a longer lyst is infix.
     ; If passed empty list, returns true (so recursion works correctly).

WikiPage SRFI-Curly modified by David A. Wheeler

David A. Wheeler — Tue, 14 Aug 2012 19:19:48 -0000

--- v34
+++ v35
@@ -62,6 +62,7 @@
 The actual implementation is trivial, except that Scheme provides no standard mechanism to override {...} in the reader.  Thus, modify the reader to hook into {...}.  We'd like implementations to always do this, but at least always do it when (enable-curly-infix) is called.
 
 ~~~~
+#!/usr/bin/guile
     ; Return true if lyst has an even # of parameters, and the (alternating)
     ; first parameters are "op".  Used to determine if a longer lyst is infix.
     ; If passed empty list, returns true (so recursion works correctly).

WikiPage SRFI-Curly modified by David A. Wheeler

David A. Wheeler — Tue, 14 Aug 2012 19:15:53 -0000

--- v33
+++ v34
@@ -30,46 +30,18 @@
 
 Lisp-based languages, like Scheme, are almost the only programming languages in modern use that do not support infix notation.  Adding infix support to Scheme would eliminate a common complaint by developers who currently choose to use other languages.  Scheme currently reserves {...} "for possible future extensions to the language".  We propose that {...} be used to support "curly-infix" notation as a reader abbreviation, just as 'x is an abbreviation for (quote x).  If the curly-infix list represents a single operator with operands, it is immediately transformed to (operator operands); otherwise, it becomes (nfx original-parameters) for later precedence processing.
 
-
-Specification
-=============
-
-"Curly-infix-expressions" (c-expressions) are s-expressions with an additional notation: The curly-infix list.  A curly-infix list is syntactically identical to a normal list, except it is surrounded by curly braces instead of by parentheses.  Once a curly-infix list is read, it is mapped differently than a regular list, depending on whether or not it is simple.  A simple curly-infix list is a curly-infix list that represents a single infix operation (it has an odd number of parameters, at least three parameters, and all even parameters are "eq?" symbols); a simple curly-infix list is mapped by the reader into a list with the even parameter followed by the odd parameters.  A non-simple curly-infix list is mapped to the list with the symbol "nfx" added to its front.
-
-A "curly-infix-expression" datum reader is a reader that can correctly read curly-infix-expressions.
-
-Here are some examples:
-
-*   {n <= 2} maps to (<= n 2)
-*   {2 * 3 * 4} maps to (* 2 3 4)
-*   {a * {b + c}} maps to (* a (+ b c))
-*   {q + r * s} maps to (nfx q + r * s)
-*   {x eqv? 'a} maps to (eqv? x 'a)
-*   {(- a) / b} maps to (/ (- a) b)
-*   {(f a b) + (g h)} maps to (+ (f a b) (g h))
-*   '{a + (f b) + x} maps to '(+ a (f b) x)
-*   {{a > 0} and {b >= 1}} maps to (and (> a 0) (>= b 1))
-
-Implementations must provide the function (curly-infix-read . port) to implement this functionality.  In addition, the function (enable-curly-infix) must enable this capability in the default reader ("read" and "get-datum"), the reader used in the REPL, and the reader used by "load".   However, we encourage systems to *always* have this capability enabled, even if enable-curly-infix is not called.
-
-Note that, by definition, this SRFI modifies lexical syntax.
-
 Rationale
 =========
 
-Lisp-based languages, like Scheme, are almost the only programming languages in modern use that do not support infix notation.  Even some Lisp advocates, like Paul Graham, admit that they "don't find prefix math expressions natural." (http://www.paulgraham.com/pypar.html)  Paul Prescod has said, "I have more faith that you could convince the world to use Esperanto than prefix notation."  Infix is not going away; nearly new languages also include infix.  Adding infix support to Scheme would eliminate a common complaint by developers who currently choose to use other languages instead.
+Lisp-based languages, like Scheme, are almost the only programming languages in modern use that do not support infix notation.  Even some Lisp advocates, like Paul Graham, admit that they "don't find prefix math expressions natural." (http://www.paulgraham.com/pypar.html)  Paul Prescod has said, "I have more faith that you could convince the world to use Esperanto than prefix notation."  Infix is not going away; nearly all new programming languages also include infix.  Adding infix support to Scheme would eliminate a common complaint by developers who currently choose to use other languages instead.
 
 Scheme currently reserves {...} "for possible future extensions to the language".  We propose that {...} be used to support "curly-infix" notation as a reader abbreviation, just as 'x is an abbreviation for (quote x).
 
-This proposal is an extremely simple and straightforward technique for supporting infix notation.  There is no complex precedence system, all other Scheme capabilities (including macros) work unchanged, and the language remains general and homoiconic.
+This proposal is an extremely *simple* and *straightforward* technique for supporting infix notation.  There is no complex precedence system, all other Scheme capabilities (including macros) work unchanged, and Scheme remains general and homoiconic. Curly-infix expressions are just a convenient abbreviation for infix notation, just like 'x maps to (quote x). 
 
-Many previous systems have implemented "infix" systems as a named macro or function (often "nfx" meaning infix).  This looks ugly, and it does the wrong thing - the resulting list has "nfx" at the beginning, not the actual infix operator, so this approach can interfere with quoting, macros, and other capabilities.  Many of these past systems also created a whole new notation which simultaneously lost Lisp's abilities for quoting, quasiquoting, and so on.  An infix notation needs to fit into the existing notation, and it needs to be both general and homoiconic.  This proposal meets all these criteria.
+Many previous systems have implemented "infix" systems as a named macro or function (often "nfx" meaning infix).  This looks ugly, and it does the wrong thing - the resulting list always has "nfx" at the beginning, not the actual infix operator, so this approach can interfere with quoting, macros, and other capabilities.  Many of these past systems also created a whole new notation which simultaneously lost Lisp's abilities for quoting, quasiquoting, and so on.  This proposal avoids these problems.
 
-Curly-infix expressions are just a convenient abbreviation, just like 'x maps to (quote x).  Unlike most past infix work, this notation does *not* interfere with Scheme's other capabilities (e.g., macros and quoting).  For example, '{3 + 4} is equivalent to (quote (+ 3 4)).  This approach provides simple infix without precedence, which turns out to be to be quite adequate for most people anyway, along with a simple escape mechanism ("nfx") for supporting precedence where that's desired.
-
-Many past "infix" systems in Lisp also build in precedence.  However, Lisp systems often process other languages, freely mixing different languages, and thus the same symbol may have different meanings and precedence levels in different contexts.  The symbol might not even be defined where it is being used.  In addition, these precedence systems hide where lists were being created, losing homoiconicity.  Having an infix system that *forces* the use of precedence can make a system harder, not easier, to use.
-
-Unlike those past systems, curly-infix builds in basic infix support into the reader, with a simple escape mechanism to enable users to define their own precedence in the rare cases they want it.  In practice, we've found that simple infix is all that's needed most of the time.  By intentionally *not* building in a precedence system, we make things amazingly simple - we don't need to register functions, decide their order, or anything like it.  It obviously would be possible to extend this mechanism to provide a precedence system (e.g., if an expression is not simple, attempt to use various precedence rules), but such capabilities would be extensions not required by this SRFI (though some future SRFI might add it somehow).
+Many past "infix" systems for Lisp build in precedence.  However, Lisp systems often process other languages, freely mixing different languages, and thus the same symbol may have different meanings and precedence levels in different contexts.  The symbol might not even be defined where it is being used.  By avoiding precedence, a very simple yet useful infix system results.  In practice, we've found that simple infix is all that's needed most of the time.  By intentionally *not* building in a precedence system, we make things amazingly simple - we don't need to register functions, decide their order, or anything like it.  It obviously would be possible to extend this mechanism to provide a precedence system (e.g., if an expression is not simple, attempt to use various precedence rules), but such capabilities would be extensions not required by this SRFI (though some future SRFI might add it somehow).
 
 Some past efforts tried to automatically detect infix operators, but this turns out to not work well.  It's hard to express good rules for detecting infix operators, and the rules become too complex for users (e.g., "punctuation-only symbols" doesn't detect "and" or "or").  And in any case, if they were automatically detected, an escape mechanism would be needed anyway.  Allowing the user to expressly notate when infix was intended, using {...}, turns out to be far more clearer and more intuitive.  It is also very backwards-compatible: Normal lists work normally, and if you want infix, use {...}.
 
@@ -77,12 +49,11 @@
 
 Curly-infix requires that infix operators be delimited (e.g., by spaces).  This is consistent with Lisp history; operators are always delimited in traditional s-expressions (typically by left parentheses on the left, and space on the right).  It's also impractical to do otherwise; most Lisps, including Scheme, allow and predefine symbols that include characters (like "-") that are typically used for infix operators.  Many developers will put space around infix operators even in languages that don't require them, so syntactically requiring them is no burden.  In short, it is difficult to allow infix operators without delimiters, and the visual results are the same as many real-world uses in other languages, so the result appears quite customary to typical software developers.
 
-If a reader implements this SRFI, we would like it to *always* be enabled.  However, we provide "enable-curly-infix" so that implementors can make it optional, or to switch from whatever was their previous interpretation.  By having a standard mechanism for enabling it, we hope will encourage adoption.  Users should invoke "(enable-curly-infix)" before using curly-infix lists.
+If a reader implements this SRFI, we would like it to *always* be enabled.  However, we provide a "enable-curly-infix" function so that implementors can make it optional, or to switch from whatever was their previous interpretation.  By having a standard mechanism for enabling it, we hope will encourage adoption.  Users should invoke "(enable-curly-infix)" before using curly-infix lists.
 
-This is an unusually simple mechanism, but like much of any Lisp-based language, its power comes from its simplicity.  This "curly-infix" approach is from work by the "readable" project (http://readable.sourceforge.net); detailed rationale for these particular semantics are here: http://sourceforge.net/p/readable/wiki/Rationale/  If the symbol "nfx" is a problem, that could be changed, but it should be a symbol other Lisps can represent (we'd like the same mechanism to work across many Lisps).
+This is an unusually simple mechanism, but like much of any Lisp-based language, its power comes from its simplicity.
 
-Note that this is the first of three tiers developed by the "readable" project.  We intend to later submit two more SRFIs, for defining the other two tiers that build on top of curly-infix-expressions.  More information about the readable project is available at: http://readable.sourceforge.net.
-
+Note that this is the first of three tiers developed by the "readable" project.  We intend to later submit two more SRFIs, for defining the other two tiers that build on top of curly-infix-expressions.
 
 Reference implementation
 ========================
@@ -139,6 +110,33 @@
     ; until its matching #\}, then process that list with "process-curly".
 ~~~~
 
+
+
+Specification
+=============
+
+"Curly-infix-expressions" (c-expressions) are s-expressions with an additional notation: The curly-infix list.  A curly-infix list is syntactically identical to a normal list, except it is surrounded by curly braces instead of by parentheses.  Once a curly-infix list is read, it is mapped differently than a regular list, depending on whether or not it is simple.  A simple curly-infix list is a curly-infix list that represents a single infix operation (it has an odd number of parameters, at least three parameters, and all even parameters are "eq?" symbols); a simple curly-infix list is mapped by the reader into a list with the even parameter followed by the odd parameters.  A non-simple curly-infix list is mapped to the list with the symbol "nfx" added to its front.
+
+A "curly-infix-expression" datum reader is a reader that can correctly read curly-infix-expressions.
+
+Here are some examples:
+
+*   {n <= 2} maps to (<= n 2)
+*   {2 * 3 * 4} maps to (* 2 3 4)
+*   {a * {b + c}} maps to (* a (+ b c))
+*   {q + r * s} maps to (nfx q + r * s)
+*   {x eqv? 'a} maps to (eqv? x 'a)
+*   {(- a) / b} maps to (/ (- a) b)
+*   {(f a b) + (g h)} maps to (+ (f a b) (g h))
+*   '{a + (f b) + x} maps to '(+ a (f b) x)
+*   {{a > 0} and {b >= 1}} maps to (and (> a 0) (>= b 1))
+
+Implementations must provide the function (curly-infix-read . port) to implement this functionality.  In addition, the function (enable-curly-infix) must enable this capability in the default reader ("read" and "get-datum"), the reader used in the REPL, and the reader used by "load".   However, we encourage systems to *always* have this capability enabled, even if enable-curly-infix is not called.
+
+Note that, by definition, this SRFI modifies lexical syntax.
+
+
+
 References
 ==========

WikiPage SRFI-Curly modified by David A. Wheeler

David A. Wheeler — Tue, 14 Aug 2012 18:41:03 -0000

--- v32
+++ v33
@@ -48,6 +48,7 @@
 *   {(- a) / b} maps to (/ (- a) b)
 *   {(f a b) + (g h)} maps to (+ (f a b) (g h))
 *   '{a + (f b) + x} maps to '(+ a (f b) x)
+*   {{a > 0} and {b >= 1}} maps to (and (> a 0) (>= b 1))
 
 Implementations must provide the function (curly-infix-read . port) to implement this functionality.  In addition, the function (enable-curly-infix) must enable this capability in the default reader ("read" and "get-datum"), the reader used in the REPL, and the reader used by "load".   However, we encourage systems to *always* have this capability enabled, even if enable-curly-infix is not called.