On Mon, Aug 27, 2012 at 3:31 PM, Shiro Kawai <xxxxxx@lava.net> wrote:
> From: Alan Manuel Gloria <xxxxxx@gmail.com>
> Subject: Re: SRFI 105: Curly-infix-expressions
> Date: Mon, 27 Aug 2012 14:14:11 +0800
>
>> Dunno.  But one major use of curly-infix in my own code is
>> with comparison operators like > < =
>>
>> WAAY back in kindergarten my teachers taught me to view
>>> as a mouth.  The mouth wants to eat the bigger thing, so
>> it faces the bigger thing.  If it's >, the bigger thing is on the
>> left, while if it's <, the bigger thing is on the right.
>
> That's a good argument.  I do prefer comparison ops infix.
>
>> We want to reserve the "{" and "}" symbols now for curly-infix,
>> and the community can vote with its feet (i.e. by using or
>> not using particular `nfx` implementations) on what precedence
>> system to use.
>
> Layering is a good idea.  If we take this approach, we can
> make responsibilities for each step more clearly separated;
> that is, one layer simply maps {a b c} to (nfx a b c), and
> another layer specifies the default behavior of nfx macro,
> which implements 0, 1, 2-ary and simple C-expr cases.
> Those don't need to be separate srfis; just multiple layers.
>
> Putting responsibility of transformation solely on a macro
> may have some benefits:
>
> - The current way of nfx specification seems like an ad-hoc
>   escape exit.

The way the current spec is done allows for code like the
following:

(define {a // b}
  {(unwrap-par-monad a) parallel (unwrap-par-monad b)})

If {a // b} => (nfx a // b), then it becomes a redefinition of
nfx as a function, rather than an intended definition of
//

Also:

(define-syntax o
  (syntax-rules ()
    ({a o b}
      (lambda (x) (b (a x))))
    ({a o b o rest o ...}
     {{a o b} o rest o ...})))

Again, this takes advantage of the fact that
{a o b o rest o ...} means (o a b rest ...)

Sincerely,
AmkG