Re: SRFI 105: Curly-infix-expressions
Shiro Kawai 27 Aug 2012 07:31 UTC
>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.
- I think whether the following C-expr is 'simple' or not
depends on implementation, correct?
`{x ,op y ,op z}
Having reader to recognize simple C-exprs might introduce
nasty edge cases. If macro handles transformation, the
behavior would be more predictable.
- Scope of reader extension isn't well defined. If an
implementation provides multiple extensions of C-exprs
(either through nfx or transform-mixed-infix), when and
how those are used? Each implementation would have its
own rules; it'd be pretty wild. On the other hand, the
scope of macros (in terms of module systems) is pretty
well defined.
The reason why you didn't take this approach may be possible
interferences with n-expressions. If so, I'd like to see
the reasoning noted in the srfi, or (I prefer) modifying
the way n-expressions work so that it can work with
"macro-transfers-all" approach.
--shiro