Recent changes to R7RS

WikiPage R7RS modified by David A. Wheeler

David A. Wheeler — Mon, 13 Aug 2012 12:14:15 -0000

--- v36
+++ v37
@@ -25,7 +25,7 @@
 
 Background: 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."   Paul Prescod has said, "I have more faith that you could convince the world to use Esperanto than prefix notation."  Adding infix support to Scheme would eliminate a common complaint by developers who currently choose to use other languages.  Draft R7RS, like versions before it, reserves {...} "for possible future extensions to the language".  We propose that {...} be used to support "curly-infix" notation, which provides infix support in the reader.  It is defined as follows:
 
-A list contained in {...} is a "curly-infix" list.  Its internal syntax is the same as a regular list, but once the list is read, it is mapped differently.  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 translated, by the datum reader, into a list with the even parameter followed by the odd parameters.  A curly-infix list that is not simple is mapped to that list with the symbol "nfx" in front.
+A list contained in {...} is a "curly-infix" list.  Its internal syntax is the same as a regular list, but once the list is read, it is mapped differently by the reader.  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 translated, by the datum reader, into a list with the even parameter followed by the odd parameters.  A curly-infix list that is not simple is mapped to that list with the symbol "nfx" in front.
 
 Here are some examples:
 
@@ -34,7 +34,7 @@
 *   {a * {b + c}} maps to (* a (+ b c))
 *   {q + r * s} maps to (nfx q + r * s)
 
-This is just a convenient abbreviation, just like 'x maps to (quote x).  Notice that unlike most past infix work, this notation does *not* interfere with Scheme's other capabilities (e.g., macros and quoting); e.g., '{3 + 4} is equivalent to (quote (+ 3 4)).  This approach provides simple infix without precedence, which turns out to be to be quite enough for most people anyway, along with a simple escape mechanism ("nfx") for supporting precedence where that's desired.
+This is just a convenient abbreviation, just like 'x maps to (quote x).  Notice that unlike most past infix work, this notation does *not* interfere with Scheme's other capabilities (e.g., macros and quoting); e.g., '{3 + 4} is equivalent to (quote (+ 3 4)).  It allows any symbol to be used as infix; there is no "registration" or any other complexity.  This approach provides simple infix without precedence, which turns out to be to be quite enough for most people anyway, along with a simple escape mechanism ("nfx") for supporting precedence where that's desired.
 
 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).

WikiPage R7RS modified by David A. Wheeler

David A. Wheeler — Mon, 13 Aug 2012 12:12:40 -0000

--- v35
+++ v36
@@ -40,4 +40,6 @@
 
 We could provide specific text for the standard for WG1, if desired.   We understand if this is considered too late for WG1, and we suspect some might want it to go to WG2 or go through the SRFI channel first.  Even in those cases, we'd like to spark some discussion now, hear feedback, and make sure that current decisions do not eliminate this as a future possible option.  We're currently developing a SRFI proposal regardless, and to help get it widely implemented; please let us know if you're interested in participating in that.
 
+If this isn't accepted, would the group be willing to entertain adding braces and brackets to the delimiter list?  They are already not allowed in portable identifiers, and this would simplify implementation somewhat.
+
 Thanks for your time.

WikiPage R7RS modified by David A. Wheeler

David A. Wheeler — Sun, 12 Aug 2012 23:56:15 -0000

--- v34
+++ v35
@@ -36,7 +36,7 @@
 
 This is just a convenient abbreviation, just like 'x maps to (quote x).  Notice that unlike most past infix work, this notation does *not* interfere with Scheme's other capabilities (e.g., macros and quoting); e.g., '{3 + 4} is equivalent to (quote (+ 3 4)).  This approach provides simple infix without precedence, which turns out to be to be quite enough for most people anyway, along with a simple escape mechanism ("nfx") for supporting precedence where that's desired.
 
-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: https://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.  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).
 
 We could provide specific text for the standard for WG1, if desired.   We understand if this is considered too late for WG1, and we suspect some might want it to go to WG2 or go through the SRFI channel first.  Even in those cases, we'd like to spark some discussion now, hear feedback, and make sure that current decisions do not eliminate this as a future possible option.  We're currently developing a SRFI proposal regardless, and to help get it widely implemented; please let us know if you're interested in participating in that.

WikiPage R7RS modified by David A. Wheeler

David A. Wheeler — Sun, 12 Aug 2012 23:55:39 -0000

--- v33
+++ v34
@@ -36,7 +36,7 @@
 
 This is just a convenient abbreviation, just like 'x maps to (quote x).  Notice that unlike most past infix work, this notation does *not* interfere with Scheme's other capabilities (e.g., macros and quoting); e.g., '{3 + 4} is equivalent to (quote (+ 3 4)).  This approach provides simple infix without precedence, which turns out to be to be quite enough for most people anyway, along with a simple escape mechanism ("nfx") for supporting precedence where that's desired.
 
-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 (readable.sourceforge.net); detailed rationale for these particular semantics are here: https://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.  This "curly-infix" approach is from work by the "readable" project (http://readable.sourceforge.net); detailed rationale for these particular semantics are here: https://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).
 
 We could provide specific text for the standard for WG1, if desired.   We understand if this is considered too late for WG1, and we suspect some might want it to go to WG2 or go through the SRFI channel first.  Even in those cases, we'd like to spark some discussion now, hear feedback, and make sure that current decisions do not eliminate this as a future possible option.  We're currently developing a SRFI proposal regardless, and to help get it widely implemented; please let us know if you're interested in participating in that.

WikiPage R7RS modified by David A. Wheeler

David A. Wheeler — Sun, 12 Aug 2012 23:55:10 -0000

--- v32
+++ v33
@@ -34,7 +34,7 @@
 *   {a * {b + c}} maps to (* a (+ b c))
 *   {q + r * s} maps to (nfx q + r * s)
 
-This is just a convenient abbreviation, just like 'x maps to (quote x).  Notice that unlike most past infix work, this notation does *not* interfere with Scheme's other capabilities (e.g., macros and quoting); e.g., '{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.
+This is just a convenient abbreviation, just like 'x maps to (quote x).  Notice that unlike most past infix work, this notation does *not* interfere with Scheme's other capabilities (e.g., macros and quoting); e.g., '{3 + 4} is equivalent to (quote (+ 3 4)).  This approach provides simple infix without precedence, which turns out to be to be quite enough for most people anyway, along with a simple escape mechanism ("nfx") for supporting precedence where that's desired.
 
 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 (readable.sourceforge.net); detailed rationale for these particular semantics are here: https://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).

WikiPage R7RS modified by David A. Wheeler

David A. Wheeler — Sun, 12 Aug 2012 23:53:49 -0000

--- v31
+++ v32
@@ -38,6 +38,6 @@
 
 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 (readable.sourceforge.net); detailed rationale for these particular semantics are here: https://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).
 
-We could provide specific text for the standard for WG1, if desired.   We understand if this is considered too late for WG1, and we suspect some might want it to go to WG2 or go through the SRFI channel first.  Even in those cases, we'd like to spark some discussion now, hear feedback, and make sure that current decisions do not eliminate this as a future possible option.  We're currently developing a SRFI proposal; please let us know if you're interested in participating in that.
+We could provide specific text for the standard for WG1, if desired.   We understand if this is considered too late for WG1, and we suspect some might want it to go to WG2 or go through the SRFI channel first.  Even in those cases, we'd like to spark some discussion now, hear feedback, and make sure that current decisions do not eliminate this as a future possible option.  We're currently developing a SRFI proposal regardless, and to help get it widely implemented; please let us know if you're interested in participating in that.
 
 Thanks for your time.

WikiPage R7RS modified by David A. Wheeler

David A. Wheeler — Sun, 12 Aug 2012 22:47:27 -0000

--- v30
+++ v31
@@ -19,7 +19,9 @@
 
 Full Description:
 
-This is an informal comment which proposes an *enhancement* called "curly-infix" support.  We think it's *major* (though others may disagree!), and it applies to "Lexical conventions".  It proposes a simple infix notation support approach that, unlike some past approaches, does not interfere with Scheme's other capabilities (e.g., macros and quoting).  If it's too late to be considered by WG1 (likely!), we'd still like to spark discussion (see below).
+This is an informal comment which proposes an *enhancement* called "curly-infix" support.  We think it's *major* (though others may disagree!), and it applies to "Lexical conventions".  It proposes a simple infix notation support approach that, unlike some past approaches, does not interfere with Scheme's other capabilities (e.g., macros and quoting).
+
+If it's too late to be considered by WG1 (likely!), we'd still like to spark discussion (see below).
 
 Background: 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."   Paul Prescod has said, "I have more faith that you could convince the world to use Esperanto than prefix notation."  Adding infix support to Scheme would eliminate a common complaint by developers who currently choose to use other languages.  Draft R7RS, like versions before it, reserves {...} "for possible future extensions to the language".  We propose that {...} be used to support "curly-infix" notation, which provides infix support in the reader.  It is defined as follows:
 
@@ -36,6 +38,6 @@
 
 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 (readable.sourceforge.net); detailed rationale for these particular semantics are here: https://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).
 
-We could provide specific text for the standard for WG1, if desired.   We understand if this is considered too late for WG1, and I suspect some might want it to go to WG2 or go through the SRFI channel first.  Even in those cases, we'd like to spark some discussion now, hear feedback, and make sure that current decisions do not eliminate this as a future possible option.  We're currently developing a SRFI proposal; please let us know if you're interested in participating in that.
+We could provide specific text for the standard for WG1, if desired.   We understand if this is considered too late for WG1, and we suspect some might want it to go to WG2 or go through the SRFI channel first.  Even in those cases, we'd like to spark some discussion now, hear feedback, and make sure that current decisions do not eliminate this as a future possible option.  We're currently developing a SRFI proposal; please let us know if you're interested in participating in that.
 
 Thanks for your time.

WikiPage R7RS modified by David A. Wheeler

David A. Wheeler — Sun, 12 Aug 2012 21:52:56 -0000

--- v29
+++ v30
@@ -23,7 +23,7 @@
 
 Background: 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."   Paul Prescod has said, "I have more faith that you could convince the world to use Esperanto than prefix notation."  Adding infix support to Scheme would eliminate a common complaint by developers who currently choose to use other languages.  Draft R7RS, like versions before it, reserves {...} "for possible future extensions to the language".  We propose that {...} be used to support "curly-infix" notation, which provides infix support in the reader.  It is defined as follows:
 
-A list contained in {...} is a "curly-infix" list.  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 translated, by the datum reader, into a list with the even parameter followed by the odd parameters.  A curly-infix list that is not simple is mapped to that list with the symbol "nfx" in front.
+A list contained in {...} is a "curly-infix" list.  Its internal syntax is the same as a regular list, but once the list is read, it is mapped differently.  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 translated, by the datum reader, into a list with the even parameter followed by the odd parameters.  A curly-infix list that is not simple is mapped to that list with the symbol "nfx" in front.
 
 Here are some examples:

WikiPage R7RS modified by David A. Wheeler

David A. Wheeler — Sun, 12 Aug 2012 21:51:05 -0000

--- v28
+++ v29
@@ -13,7 +13,7 @@
 =========================
 
 One-sentence summary of issue: Add curly-infix {...} to support infix expressions
-Name: David A. Wheeler
+Name: David A. Wheeler and Alan Manuel Gloria
 Email: dwheeler at dwheeler dot com
 Version: Draft 6 (really all)

WikiPage R7RS modified by David A. Wheeler

David A. Wheeler — Sun, 12 Aug 2012 21:50:46 -0000

--- v27
+++ v28
@@ -19,7 +19,7 @@
 
 Full Description:
 
-This is an informal comment which proposes an *enhancement* called "curly-infix" support.  We think it's *major* (though others may disagree!), and it applies to "Lexical conventions".  It proposes a simple infix notation support approach that, unlike some past approaches, does not interfere with Scheme's other capabilities (e.g., macros and quoting).  If it's too late to be considered by WG1, we'd still like to spark discussion (see below).
+This is an informal comment which proposes an *enhancement* called "curly-infix" support.  We think it's *major* (though others may disagree!), and it applies to "Lexical conventions".  It proposes a simple infix notation support approach that, unlike some past approaches, does not interfere with Scheme's other capabilities (e.g., macros and quoting).  If it's too late to be considered by WG1 (likely!), we'd still like to spark discussion (see below).
 
 Background: 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."   Paul Prescod has said, "I have more faith that you could convince the world to use Esperanto than prefix notation."  Adding infix support to Scheme would eliminate a common complaint by developers who currently choose to use other languages.  Draft R7RS, like versions before it, reserves {...} "for possible future extensions to the language".  We propose that {...} be used to support "curly-infix" notation, which provides infix support in the reader.  It is defined as follows:
 
@@ -36,6 +36,6 @@
 
 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 (readable.sourceforge.net); detailed rationale for these particular semantics are here: https://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).
 
-We could provide specific text for the standard for WG1, if desired.   We understand if this is considered too late for WG1, and I suspect some might want it to go to WG2 or go through the SRFI channel first. Even in those cases, we'd like to spark some discussion now, hear feedback, and make sure that current decisions do not eliminate this as a future possible option.
+We could provide specific text for the standard for WG1, if desired.   We understand if this is considered too late for WG1, and I suspect some might want it to go to WG2 or go through the SRFI channel first.  Even in those cases, we'd like to spark some discussion now, hear feedback, and make sure that current decisions do not eliminate this as a future possible option.  We're currently developing a SRFI proposal; please let us know if you're interested in participating in that.
 
 Thanks for your time.