R7RS

All - please comment! The following draft is for posting to the R7RS group.

I currently plan to submit it to the WG1 mailing list:

https://groups.google.com/forum/?fromgroups#!forum/scheme-reports-wg1

Though perhaps, alternatively, it should be sent to the scheme-reports mailing list:

http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

My current plan is to submit an "informal" comment, but provide the info like a formal comment. We've missed the cutoff date for the sixth draft of "small" R7RS, and it's not clear there will be another round, but we can still try for "large" and get some feedback.

=========================

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

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).

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 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:

• {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)

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).

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.