[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: shiro@xxxxxxxx*Subject*: Re: SRFI 105: Curly-infix-expressions*From*: "David A. Wheeler" <dwheeler@xxxxxxxxxxxx>*Date*: Mon, 27 Aug 2012 08:27:16 -0400 (EDT)*Cc*: srfi-105@xxxxxxxxxxxxxxxxx, almkglor@xxxxxxxxx*Delivered-to*: srfi-105@xxxxxxxxxxxxxxxxx*In-reply-to*: <20120826.213139.1108322852317673718.shiro@xxxxxxxx>*References*: <E1T5nSK-00084G-6i@xxxxxxxxxxxxxxxxx> <20120826.182304.931495076416921545.shiro@xxxxxxxx> <CAF+kUQWBRMkf48gjQdp9GoEhiv9t209=f_t=iWtxCd5m_Zv5zw@xxxxxxxxxxxxxx> <20120826.213139.1108322852317673718.shiro@xxxxxxxx>*Reply-to*: dwheeler@xxxxxxxxxxxx

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.

**Follow-Ups**:**Re: SRFI 105: Curly-infix-expressions***From:*John Cowan

**Re: SRFI 105: Curly-infix-expressions***From:*Shiro Kawai

**References**:**Re: SRFI 105: Curly-infix-expressions***From:*David A. Wheeler

**Re: SRFI 105: Curly-infix-expressions***From:*Shiro Kawai

**Re: SRFI 105: Curly-infix-expressions***From:*Alan Manuel Gloria

**Re: SRFI 105: Curly-infix-expressions***From:*Shiro Kawai

- Prev by Date:
**Re: SRFI 105: Curly-infix-expressions** - Next by Date:
**Re: SRFI 105: Curly-infix-expressions** - Previous by thread:
**Re: SRFI 105: Curly-infix-expressions** - Next by thread:
**Re: SRFI 105: Curly-infix-expressions** - Index(es):