This page is part of the web mail archives of SRFI 105 from before July 7th, 2015. The new archives for SRFI 105 contain all messages, not just those from before July 7th, 2015.
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.