Recent changes to SRFI-Neoteric

WikiPage SRFI-Neoteric modified by David A. Wheeler

David A. Wheeler — Fri, 17 Aug 2012 04:51:27 -0000

--- v46
+++ v47
@@ -92,7 +92,7 @@
 * 'f(x) maps to '(f x)
 * my-read(. port) maps to (my-read . port)
 * {-(x) * y} maps to (* (- x) y)
-* 'g(h ,k) maps to '(g h ,k)
+* 'g(,h k) maps to '(g ,h k)
 * factorial{n - 1} maps to (factorial (- n 1))
 * band(foo {x + 1}) maps to (band foo (+ x 1))
 * a\[x] maps to (bracketaccess a x)

WikiPage SRFI-Neoteric modified by David A. Wheeler

David A. Wheeler — Fri, 17 Aug 2012 04:50:26 -0000

--- v45
+++ v46
@@ -217,7 +217,7 @@
 Part 2: Reader re-implementation
 --------------------------------
 
-Here is the second part. This is a reader re-implementation, suitable so you can try it out in standard Scheme.  The following provide the functions for supporting curly infix, support for a reader, a reader, and a demo.
+Here is the second part. This is a reader re-implementation, suitable so you can try it out in standard Scheme.  It implements R5RS, plus a few pieces from R6RS and some extensions, which is sufficient to show how to create a neoteric-expression reader. The following provide the functions for supporting curly infix, support for a reader, a reader, and a demo.
 
 ~~~~
 ; -----------------------------------------------------------------------------

WikiPage SRFI-Neoteric modified by David A. Wheeler

David A. Wheeler — Fri, 17 Aug 2012 04:48:30 -0000

--- v44
+++ v45
@@ -121,11 +121,10 @@
 Reference implementation
 ========================
 
-This implementation is in two parts.
-
-The first part provides the few functions needed to modify an existing reader that already supports curly-infix and includes brackets and braces as delimiters.  You can simply modify the reader to call neoteric-process-tail as described below.
-
-The second part re-implements a Scheme reader to call these functions.  This part illustrates how to use the first part, and also provides a complete portable implementation of neoteric-read.
+This implementation is in two parts:
+
+1.   The first part provides the few functions needed to modify an existing reader that already supports curly-infix and includes brackets and braces as delimiters.  You can simply modify the reader to call neoteric-process-tail as described below.
+2.   The second part re-implements a Scheme reader to call these functions.  This part illustrates how to use the first part, and also provides a complete portable implementation of neoteric-read.
 
 In both parts the code is 100% portable R5RS, which the exception of the use of "(force-output)" in the optional demo code at the very end.  The demo isn't actually part of the reader, it just creates a loop so you can read in expressions and see what they produce.  The call to force-output call can be trivially removed.  The force-output flushing lets you feed results elsewhere to be acted on immediately, e.g., "guile srfi-neoteric.scm | guile".

WikiPage SRFI-Neoteric modified by David A. Wheeler

David A. Wheeler — Fri, 17 Aug 2012 04:47:29 -0000

--- v43
+++ v44
@@ -129,6 +129,8 @@
 
 In both parts the code is 100% portable R5RS, which the exception of the use of "(force-output)" in the optional demo code at the very end.  The demo isn't actually part of the reader, it just creates a loop so you can read in expressions and see what they produce.  The call to force-output call can be trivially removed.  The force-output flushing lets you feed results elsewhere to be acted on immediately, e.g., "guile srfi-neoteric.scm | guile".
 
+Part 1: Key functions
+---------------------
 
 ~~~~
 ; -----------------------------------------------------------------------------
@@ -212,6 +214,9 @@
   ;     prefix
   ;     (neoteric-process-tail port prefix)))
 ~~~~
+
+Part 2: Reader re-implementation
+--------------------------------
 
 Here is the second part. This is a reader re-implementation, suitable so you can try it out in standard Scheme.  The following provide the functions for supporting curly infix, support for a reader, a reader, and a demo.

WikiPage SRFI-Neoteric modified by David A. Wheeler

David A. Wheeler — Fri, 17 Aug 2012 04:45:42 -0000

--- v42
+++ v43
@@ -29,31 +29,28 @@
 Abstract
 ========
 
-Lisp-based languages, like Scheme, use a function call notation that is significantly different than practically all other programming languages and traditional math textbooks, yet there is no reason they need to.  Neoteric-expressions (n-expressions) start with curly-infix-expressions, but modify the syntax slightly so that e(x) maps to (e x), e{x} maps to (e {x}), e\[x] maps to (bracketaccess e x), and (. e) maps to e.  Neoteric-expressions are a superset of curly-infix expressions.
+Lisp-based languages, like Scheme, use a function call notation that is significantly different than practically all other programming languages and traditional math textbooks, yet there is no reason they need to.  Neoteric-expressions (n-expressions) start with curly-infix-expressions, but modify the syntax slightly to allow for some additional abbreviations.  In neoteric-expressions,  e(x) maps to (e x), e{x} maps to (e {x}), e\[x] maps to (bracketaccess e x), and (. e) maps to e.  Neoteric-expressions are a superset of curly-infix expressions.
 
 Rationale
 =========
 
 The function call notation most people are taught in school and is used by most programming languages puts the function name first, followed by the opening parenthesis.  Traditional Lisps, including Scheme, don't support this.  But there's actually no reason they cannot; the reader can be easily modified to accept e(x) as simply an abbreviation for (e x), just as 'x is an abbreviation for (quote x).  Macros, quoting, and so on are all unaffected.  This proposal makes this change.
 
-Technically this change is incompatible with past practice and standards.  But code where this difference matters is considered extremely poor style, and it is unlikely in modern code. In addition, a pretty-printer can automatically eliminate any such rare problems, so transition should be a non-problem in practice.
-
-Neoteric-expressions build on curly infix, since the prefixed {} (described below) requires handling curly infix, and users who want neoteric-expressions are likely to also want curly-expressions.
-
-Many have commented that it'd be valueable to be able to say name(x) instead of (name x):
+This does change the syntax slightly.  But code where this difference matters is considered extremely poor style and is unlikely in modern code. In addition, a pretty-printer can automatically eliminate any such rare problems, so transition should be a non-problem in practice.
+
+Others have noted the value of being able to be able to say name(x) instead of (name x):
 
 *   Peter Norvig had a reader implementation in which “if a function name ends with an open parentheses, move it inside the list (when converting to an s-expression)”.  This means that “(fact x)” and “fact(x)” will mean the same thing.
-*   Skill from Cadence, a proprietary Lisp-based extension language, also supports name-prefixing.
-*   Jorgen ‘forcer’ Schaefer argues that this is a more serious problem than the lack of infix notation; on July 2000 he said “I think most people would like Scheme a lot better if they could say lambda (expression) ...  instead of (lambda (expression) ...”
-
-The additions of neoteric-expressions combine well with curly-infix-expressions; neoteric-expressions make it easy to use unary functions. They also make it easy to call a function that takes one parameter that is calculated using infix notation (a common circumstance).  For example, {-(x) \* y} maps to (\* (- x) y), and factorial{n - 1} maps to (factorial (- n 1)).
+*   Skill from Cadence, a proprietary Lisp-based extension language, also supports placing the name in front of the list.
+
+The additions of neoteric-expressions combine well with curly-infix-expressions; neoteric-expressions make it easier to notate functions, including unary functions. They also make it easy to call a function with one parameter calculated using infix notation (a common circumstance).  For example, {-(x) \* y} maps to (\* (- x) y), and factorial{n - 1} maps to (factorial (- n 1)).
 
 The unprefixed (. e) rule provides an easy standard way to escape symbols.  Here is its rationale:
 
-*   Notations that can build on neoteric-expressions, such as sweet-expressions, need an escape mechanism for characters and symbols.  For example, sweet-expressions need a way to escape leading !, the \\\\ symbol, and the $ symbol.  It was far easier to define this escape mechanism as part of neoteric-expressions, as some other notations (like sweet-expressions) do not manipulate anything inside parentheses.
-*   This rule *could* have been defined as part of other notations such as sweet-expressions, but that would create an implementation problem.  We fully expect that implementers will work in stages; in particular, some may not want to build in indentation processing, but they might be willing to build a neoteric-expression system into their reader.  If you built a sweet-expression reader on top of a neoteric-expression reader, but that reader didn't implement (. e), then you'd have to re-implement the whole neoteric-expression reader anyway.  But if all neoteric-expression readers support (. e), then a sweet-expression reader tends to be trivial to build on top.
-*   This is already implemented in guile, so there is already a working example that this is a reasonable extension.  In fact, in some implementations of a list reader, it takes extra effort to *prevent* this extension, so this is a relatively easy extension to include.
-*   We want this notation to be portable even to Schemes that implement just R5RS and to Lisps other than Scheme.  The notation (. e) has no other meaning (that we know of) in any Lisp, so it's widely available as an escape mechanism.
+*   At least one notation designed to build on neoteric-expressions, namely sweet-expressions, needs an escape mechanism for characters and symbols.  For example, sweet-expressions need a way to escape leading !, the \\\\ symbol, and the $ symbol.  It is far easier to define this escape mechanism being as part of neoteric-expressions, as sweet-expressions do not manipulate anything inside parentheses.
+*   This rule *could* have been defined as part of other notations such as being part of sweet-expressions, but that would create an implementation problem.  We fully expect that implementers will work in stages; in particular, some may not want to build in indentation processing, but they might be willing to build a neoteric-expression system into their reader.  If you built a sweet-expression reader on top of a neoteric-expression reader, but that reader didn't implement (. e), then you'd have to re-implement the whole neoteric-expression reader anyway (even though the system has one).  But if all neoteric-expression readers support (. e), then a sweet-expression reader tends to be trivial to build on top.
+*   This extension is already implemented in guile, so there is already a working example that this is a reasonable extension.  In fact, in some implementations of a list reader, it takes extra effort to *prevent* this extension, so this is a relatively easy extension to include.
+*   We want this notation to be portable even to Schemes that implement just R5RS and to Lisps other than Scheme.  The notation (. e) has no other meaning (that we know of) in any Lisp, so it's widely available as an escape mechanism.  This improves cross-platform consistency.
 
 It would be possible to define neoteric-expressions to *require* comma-separated values in a function call. This would make it even more similar to traditional function call notation. However, this approach was rejected. Such a rule:

WikiPage SRFI-Neoteric modified by David A. Wheeler

David A. Wheeler — Fri, 17 Aug 2012 04:27:36 -0000

--- v41
+++ v42
@@ -130,7 +130,7 @@
 
 The second part re-implements a Scheme reader to call these functions.  This part illustrates how to use the first part, and also provides a complete portable implementation of neoteric-read.
 
-In both parts the code is 100% portable R5RS, which the exception of the use of "(force-output)" in the optional demo code at the end.  The demo isn't part of the reader, and the call to force-output call can be trivially removed.  The force-output flushing is used so that you can feed the execution of the processor into another Lisp implementation and try it out, e.g., "guile srfi-neoteric.scm | guile".
+In both parts the code is 100% portable R5RS, which the exception of the use of "(force-output)" in the optional demo code at the very end.  The demo isn't actually part of the reader, it just creates a loop so you can read in expressions and see what they produce.  The call to force-output call can be trivially removed.  The force-output flushing lets you feed results elsewhere to be acted on immediately, e.g., "guile srfi-neoteric.scm | guile".
 
 
 ~~~~
@@ -216,7 +216,7 @@
   ;     (neoteric-process-tail port prefix)))
 ~~~~
 
-Here is the second part. This is a demo, suitable so you can try it out in standard Scheme.  The following provide the functions for supporting curly infix, support for a reader, a reader, and a demo.
+Here is the second part. This is a reader re-implementation, suitable so you can try it out in standard Scheme.  The following provide the functions for supporting curly infix, support for a reader, a reader, and a demo.
 
 ~~~~
 ; -----------------------------------------------------------------------------

WikiPage SRFI-Neoteric modified by David A. Wheeler

David A. Wheeler — Fri, 17 Aug 2012 04:24:26 -0000

--- v40
+++ v41
@@ -103,7 +103,7 @@
 * "hello"(2 4) maps to ("hello" 2 4)
 * (. !x) maps to !x
 * f(x)(q) maps to ((f x) q)
-* lambda((x) {x + x})(4) maps to ((lambda (x) {x + x}) 4) ... which if evaluated would produce 8.
+* lambda((x) {x + x})(4) maps to ((lambda (x) (+ x x)) 4) ... which if evaluated would produce 8.
 
 Note that square brackets and curly braces must be delimiters (so that they will not be consumed as parts of symbols); this is consistent with but extends curly-infix notation, which requires that curly braces be delimiters.

WikiPage SRFI-Neoteric modified by David A. Wheeler

David A. Wheeler — Fri, 17 Aug 2012 04:21:06 -0000

--- v39
+++ v40
@@ -130,9 +130,7 @@
 
 The second part re-implements a Scheme reader to call these functions.  This part illustrates how to use the first part, and also provides a complete portable implementation of neoteric-read.
 
-In both parts the code is 100% portable R5RS, which the exception of the use of "(force-output)" in the demo code at the end.  The demo isn't actually part of the reader, and it can be trivially removed.  The force-output flushing is used so that you can feed the execution of the processor into another Lisp implementation and try it out, e.g.:
-
-    guile srfi-neoteric.scm | guile
+In both parts the code is 100% portable R5RS, which the exception of the use of "(force-output)" in the optional demo code at the end.  The demo isn't part of the reader, and the call to force-output call can be trivially removed.  The force-output flushing is used so that you can feed the execution of the processor into another Lisp implementation and try it out, e.g., "guile srfi-neoteric.scm | guile".
 
 
 ~~~~

WikiPage SRFI-Neoteric modified by David A. Wheeler

David A. Wheeler — Fri, 17 Aug 2012 04:19:25 -0000

--- v38
+++ v39
@@ -129,6 +129,10 @@
 The first part provides the few functions needed to modify an existing reader that already supports curly-infix and includes brackets and braces as delimiters.  You can simply modify the reader to call neoteric-process-tail as described below.
 
 The second part re-implements a Scheme reader to call these functions.  This part illustrates how to use the first part, and also provides a complete portable implementation of neoteric-read.
+
+In both parts the code is 100% portable R5RS, which the exception of the use of "(force-output)" in the demo code at the end.  The demo isn't actually part of the reader, and it can be trivially removed.  The force-output flushing is used so that you can feed the execution of the processor into another Lisp implementation and try it out, e.g.:
+
+    guile srfi-neoteric.scm | guile
 
 
 ~~~~
@@ -561,6 +565,7 @@
         ((not (eof-object? result))
           (write result)
           (display "\n")
+          (force-output)  ; flush, so can interactively control something else
           (process-input)))))
 
   (process-input)

WikiPage SRFI-Neoteric modified by David A. Wheeler

David A. Wheeler — Fri, 17 Aug 2012 04:00:55 -0000

--- v37
+++ v38
@@ -101,6 +101,7 @@
 * a\[x] maps to (bracketaccess a x)
 * a\[x y] maps to (bracketaccess a x y)
 * "hello"(2 4) maps to ("hello" 2 4)
+* (. !x) maps to !x
 * f(x)(q) maps to ((f x) q)
 * lambda((x) {x + x})(4) maps to ((lambda (x) {x + x}) 4) ... which if evaluated would produce 8.