Shiro Kawai:
> - I think whether the following C-expr is 'simple' or not
>   depends on implementation, correct?
>     `{x ,op y ,op z}

Correct.  We could *require* support for this.  The "easy" way would be to require use of "equal?".

>   Having reader to recognize simple C-exprs might introduce
>   nasty edge cases.  If macro handles transformation, the
>   behavior would be more predictable.

No, that'd be horrible.  I don't care if the underlying reader uses macros to implement itself, that's fine.  But when (read) is done, it is *critically* important that {+ a b} produce the list (+ a b).  There are lots of "infix" systems today that generate FUNNY_SYMBOL as the first position.  That's not what an infix system is about; the point is to put the OPERATOR into the operator position, not FUNNY_SYMBOL.

> - 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 reader scope is easy: ALWAYS.  EVERYWHERE.  ALL the time.  It affects read, load, REPL, and even get-datum if you have it.  If there's some other case that should be mentioned, please let us know so we can add it.

Regarding "nfx": The reader returns a list with the "nfx" symbol in the front.  The user then decides what to do.  There's *NO* requirement that the result *EVER* be passed to eval, by the way; the user might have a completely different process for handling the result from read.  This adds flexibility at little cost.

The "transform-mixed-infix" should NEVER be changed by the user, as documented in the SRFI.  That is intended as a trapdoor for future SRFIs.  Note that "transform-mixed-infix" is NOT a requirement, it's just that an implementation MAY define it.

> 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.