Email list hosting service & mailing list manager


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) &#8658; (f 1 2), exit() &#8658; (exit), and read(. port) &#8658; (read . port).
*   An e{} maps to (e), otherwise, e{...} maps to (e {...}). E.g., f{n - 1} &#8658; (f {n - 1}) &#8658; (f (- n 1)), and g{- x} &#8658; (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