Recent changes to Solution

Solution modified by David A. Wheeler

David A. Wheeler — Sun, 10 Sep 2017 21:06:09 -0000

--- v179
+++ v180
@@ -57,7 +57,7 @@

 Beginning an expression with indentation causes that line's indentation to be ignored, improving backwards compatibility.  We recommend that editors highlight these lines as warnings, to reduce the risk of their accidental use.  It might be also useful for an editor to highlight blank lines (as they separate expressions) and lines beginning at the left column.

-Our goal is to devise general abbreviations that others can build on if they choose.  Individual implementations may have *additional* abbreviations that are useful for their semantics, or extensions to the rules listed above.  For example, the Scheme and Common Lisp sample implementations of sweet-expressions also implement line continuation (use "\\\\" at the end of a line, after at least one expression, and the next line will be a continuation if it has the same indentation).
+Our goal is to devise general abbreviations that others can build on if they choose.  Individual implementations may have *additional* abbreviations that are useful for their semantics, or extensions to the rules listed above.  For example, the Scheme and Common Lisp sample implementations of sweet-expressions also implement line continuation (use "\\\\" at the end of a line, after at least one expression, and the next line will be a continuation if it has at least the same indentation level).

 This is version 1.0 of our notation specification.

Solution modified by David A. Wheeler

David A. Wheeler — Sun, 10 Sep 2017 21:04:42 -0000

--- v178
+++ v179
@@ -57,7 +57,7 @@

 Beginning an expression with indentation causes that line's indentation to be ignored, improving backwards compatibility.  We recommend that editors highlight these lines as warnings, to reduce the risk of their accidental use.  It might be also useful for an editor to highlight blank lines (as they separate expressions) and lines beginning at the left column.

-Individual implementations may have *additional* abbreviations that are useful for their semantics; our goal is to devise general abbreviations that others can build on if they choose.
+Our goal is to devise general abbreviations that others can build on if they choose.  Individual implementations may have *additional* abbreviations that are useful for their semantics, or extensions to the rules listed above.  For example, the Scheme and Common Lisp sample implementations of sweet-expressions also implement line continuation (use "\\\\" at the end of a line, after at least one expression, and the next line will be a continuation if it has the same indentation).

 This is version 1.0 of our notation specification.

Solution modified by David A. Wheeler

David A. Wheeler — Thu, 14 Jul 2016 20:09:00 -0000

--- v177
+++ v178
@@ -19,14 +19,14 @@
     * By intent, there is no precedence; just use another list. E.g., {2 + {3 * 4}} ⇒ (+ 2 (\* 3 4))
     * There are two variations of curly-infix notation, "basic" and "full".  In "basic" c-expressions, each element in a regular or infix list is another basic c-expression.  In "full" c-expressions, each element is a neoteric-expression, as defined below; that means inside {} you can use f(x) to represent (f x).
     * Full c-expressions are defined for Scheme in [SRFI 105](http://srfi.schemers.org/srfi-105/).
-2.   *Neoteric-expressions* (*n-expressions*): This includes curly-infix-expressions, and adds special meanings to some prefixed expressions.
+2.   *Neoteric-expressions* (*n-expressions*): This (normally) includes curly-infix-expressions, and adds special meanings to some prefixed expressions.
     * An e(...) maps to (e ...).  E.g., f(1 2) ⇒ (f 1 2), exit() ⇒ (exit), and read(. port) ⇒ (read . port).
     * An e{} maps to (e), otherwise, e{...} maps to (e {...}). E.g., f{n - 1} ⇒ (f {n - 1}) ⇒ (f (- n 1)), and g{- x} ⇒ (g (- x)).
     * An e\[...] maps to ($bracket-apply$ e ...)
     * In the above, "e" is any datum expression. There must be no whitespace between e and the open paired character.
     * An unprefixed "( . e)" must evaluate as "e".
     * These recurse left-to-right.  E.g., f{n - 1}(x) ⇒ f({n - 1})(x) ⇒ (f (- n 1))(x) ⇒ ((f (- n 1)) x)
-    * If you want *only*
+    * A system that implements neoteric expressions without curly-infix-expressions is a "simple neoteric-expression reader".
 3.   *Sweet-expressions* (*t-expressions*): Includes neoteric-expressions, and deduce parentheses from indentation. Here are the basics:

     - A line with content consists of one or more n-expressions, separated by one or more spaces or tabs.

Solution modified by David A. Wheeler

David A. Wheeler — Thu, 14 Jul 2016 20:05:17 -0000

--- v176
+++ v177
@@ -16,7 +16,7 @@
     * The *empty* infix list {} maps to (), the *escaping* infix list {e} maps to e, and the *unary-op* infix list {e1 e2} maps to (e1 e2).  Thus, {$} ⇒ $, and {- x} ⇒ (- x).
     * Infix lists with "." as the first contained symbol have an unspecified mapping.
     * Other infix lists are mixed and map to "($nfx$ parameters)".  E.g., {2 + 3 * 4} ⇒ ($nfx$ 2 + 3 * 4)
-    * By intent, there is no precedence; just use another list. E.g., {2 + {3 * 4}} ⇒ (+ 2 (* 3 4))
+    * By intent, there is no precedence; just use another list. E.g., {2 + {3 * 4}} ⇒ (+ 2 (\* 3 4))
     * There are two variations of curly-infix notation, "basic" and "full".  In "basic" c-expressions, each element in a regular or infix list is another basic c-expression.  In "full" c-expressions, each element is a neoteric-expression, as defined below; that means inside {} you can use f(x) to represent (f x).
     * Full c-expressions are defined for Scheme in [SRFI 105](http://srfi.schemers.org/srfi-105/).
 2.   *Neoteric-expressions* (*n-expressions*): This includes curly-infix-expressions, and adds special meanings to some prefixed expressions.
@@ -26,6 +26,7 @@
     * In the above, "e" is any datum expression. There must be no whitespace between e and the open paired character.
     * An unprefixed "( . e)" must evaluate as "e".
     * These recurse left-to-right.  E.g., f{n - 1}(x) ⇒ f({n - 1})(x) ⇒ (f (- n 1))(x) ⇒ ((f (- n 1)) x)
+    * If you want *only*
 3.   *Sweet-expressions* (*t-expressions*): Includes neoteric-expressions, and deduce parentheses from indentation. Here are the basics:

     - A line with content consists of one or more n-expressions, separated by one or more spaces or tabs.

Solution modified by David A. Wheeler

David A. Wheeler — Fri, 31 Oct 2014 21:38:39 -0000

--- v175
+++ v176
@@ -5,7 +5,11 @@
 Readable abbreviation specification
 ===================================

-We have three notation tiers, each of which builds on the previous one. Curly-infix starts with traditional s-expressions and adds support for traditional infix notation; neoteric-expressions add support for traditional function notation; and sweet-expressions reduce the number of explicit parentheses needed (by deducing them from indentation).  Here's the complete specification of these abbreviations (where "⇒" means "maps to"):
+We have three notation tiers, each of which builds on the previous one. Curly-infix starts with traditional s-expressions and adds support for traditional infix notation; neoteric-expressions add support for traditional function notation; and sweet-expressions reduce the number of explicit parentheses needed (by deducing them from indentation).
+
+You do *not* need to use all three tiers.  In particular, if you don't want to use an indentation-sensitive language, you don't need to.
+
+Here's the complete specification of these abbreviations (where "⇒" means "maps to"):

 1.   *Curly-infix-expressions* (*c-expressions*): A c-expression is an s-expression or an expression surrounded by curly braces {...} called an *infix list*.
     * A *simple* infix list {a op b op c op ...} represents one operation in infix order, that is, (op a b c ...).  It has (1) an odd number of parameters, (2) at least 3 parameters, and (3) all even parameters are the same symbol (aka eq? or eq).  It maps to "(even-parameter odd-parameters)".  E.g., {n <= 2} ⇒ (<= n 2), and {7 + 8 + 9} ⇒ (+ 7 8 9).

Solution modified by David A. Wheeler

David A. Wheeler — Mon, 27 Oct 2014 02:27:06 -0000

--- v174
+++ v175
@@ -138,6 +138,19 @@
 "Letterfall" by Alan Manuel Gloria is a game written using sweet-expressions; you can see it here: https://github.com/AmkG/letterfall

+Advantages
+==========
+
+Here are some advantages of these notations:
+
+*   Generic: The notation does not depend on an underlying semantic.  If you create a new meta-language, you can keep using these notations.
+*   Homoiconic: The underlying data structure is clear from the syntax.  This is vitally important for debugging.
+*   Backwards-compatible: Normally-formatted Lisp expressions keep working unchanged.
+*   Easy to read: These notations add syntax that is easier to read by most developers.
+*   Rigorous yet easily implemented specification:  The entire stack of notations is LL(1), as verified using ANTLR.  It's been implemented three times (Java/ANTLR, Scheme, and Common Lisp), showing that the notation is quite implementable and not tied to just one system.
+*   Usable: Real programs have been implemented using these notations.
+
+
 Credits
 =======

Solution modified by David A. Wheeler

David A. Wheeler — Sat, 14 Jun 2014 14:19:20 -0000

--- v173
+++ v174
@@ -37,7 +37,6 @@
     - You can indent using one-or-more space, tab, and/or exclamation point (!) characters.
     - A line with only spaces and tabs is an empty line.  A line with at least one "!" is ignored if it only has indent characters.
     - An expression that *starts* indented enables "indented-compatibility" mode, where indentation is completely ignored (that line switches to neoteric-expressions).
-

     Sweet-expressions also include these advanced capabilities:

Solution modified by David A. Wheeler

David A. Wheeler — Sat, 14 Jun 2014 14:18:33 -0000

--- v172
+++ v173
@@ -42,9 +42,9 @@
     Sweet-expressions also include these advanced capabilities:

     - A \\\\ (aka SPLIT) starts a new line at the current indentation.  If it's immediately after indentation (aka GROUP in that case), it represents no symbol at all (at that indentation) - this is useful for lists of lists.
-    - A $ (aka SUBLIST) in the middle of list restarts list processing; the right-hand-side (including its sub-blocks) is the last parameter of the left-hand side (of just that line). If there's no left-hand-side, the right-hand-side is put in a list.
+    - A $ (aka SUBLIST) in the middle of list restarts list processing; the right-hand-side (including its sub-blocks) is the last parameter of the left-hand side (of just that line). If there's no left-hand-side, the right-hand-side is put in a list.  This useful abbreviation from Haskell simplifies many common cases.
     - A leading traditional abbreviation (quote, comma, backquote, or comma-at) or datum comment "#;", at the beginning of a sweet-expression line, and followed by space or tab or end-of-line, is that operator applied to the following sweet-expression.   Otherwise, it applies to the next neoteric-expression.
-    - The markers “<*” and “*>” surround a collecting list, and MUST accept a list of 0 or more un-indented sweet-expressions.
+    - The markers “<*” and “*>” surround a collecting list, and MUST accept a list of 0 or more un-indented sweet-expressions. The “<*” and “*>” represent opening and closing parentheses, but restart indentation processing at the beginning of the line.  A collecting list is only terminated by its matching “*>” and not by a blank line.  These are valuable for defining libraries and for short let-style constructs.
     - The marker “$$$” is reserved for future use.

     Sweet-expression examples are shown below.  For Scheme, sweet-expressions are defined in [SRFI 110](http://srfi.schemers.org/srfi-110/).

Solution modified by David A. Wheeler

David A. Wheeler — Sat, 14 Jun 2014 14:09:32 -0000

--- v171
+++ v172
@@ -13,7 +13,7 @@
     * Infix lists with "." as the first contained symbol have an unspecified mapping.
     * Other infix lists are mixed and map to "($nfx$ parameters)".  E.g., {2 + 3 * 4} ⇒ ($nfx$ 2 + 3 * 4)
     * By intent, there is no precedence; just use another list. E.g., {2 + {3 * 4}} ⇒ (+ 2 (* 3 4))
-    * There are two variations of curly-infix notation, "basic" and "full".  In "basic" c-expressions, each element (in a regular or curly-infix list) is another basic c-expression.  In "full" c-expressions, each element is a neoteric-expression, as defined below; that means inside {} you can use f(x) as (f x).
+    * There are two variations of curly-infix notation, "basic" and "full".  In "basic" c-expressions, each element in a regular or infix list is another basic c-expression.  In "full" c-expressions, each element is a neoteric-expression, as defined below; that means inside {} you can use f(x) to represent (f x).
     * Full c-expressions are defined for Scheme in [SRFI 105](http://srfi.schemers.org/srfi-105/).
 2.   *Neoteric-expressions* (*n-expressions*): This includes curly-infix-expressions, and adds special meanings to some prefixed expressions.
     * An e(...) maps to (e ...).  E.g., f(1 2) ⇒ (f 1 2), exit() ⇒ (exit), and read(. port) ⇒ (read . port).

Solution modified by David A. Wheeler

David A. Wheeler — Sat, 14 Jun 2014 14:07:19 -0000

--- v170
+++ v171
@@ -152,7 +152,7 @@
 Trying them out
 =============

-Read the [Install-howto] to learn how to install the software.
+Read the [Install-howto] to learn how to install the software.  [Prepackaged] lists some cases where the software is prepackaged for your use.

 Then look one of our two tutorials: