Re: SRFI 105: Curly-infix-expressions
David A. Wheeler 26 Aug 2012 20:35 UTC
Aubrey Jaffer <xxxxxx@alum.mit.edu>
> Is the syntax { f(x) } not handled?
As I mentioned earlier, not in straight curly-infix, because that's the role of neoteric-expressions, which I intend to submit as a separate SRFI. But if people want to support { f(x) } without necessarily supporting f(x) at the outermost level, we could modify curly-infix to do easily, by requiring support for a sequence of neoteric-expressions *inside* a curly-infix expression (recursively).
That would add a little more to the specification, though not much. Here's an example of how this would modify the current draft curly-infix specification:
~~~~
A curly-infix list contains, inside {...}, a sequence of 0 or more whitespace-separated neoteric-expressions.
A neoteric-expression is a curly-infix expression, but in addition, given a datum "e":
* 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 (bracketaccess e ...)
There must be no whitespace between e and the open paired character. Also, an unprefixed "( . e)" must evaluate as "e". Unprefixed lists contain a sequence of zero or more whitespace-separated neoteric-expressions, recursively.
~~~~
With this addition, you *CAN* have:
{f(x) + 5 + g(x y)}
and even:
{substring("Hello" 1 3)}
For rationale on the design of neoteric-expressions, see:
https://sourceforge.net/p/readable/wiki/Rationale/
--- David A. Wheeler