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.
From: Alan Manuel Gloria <almkglor@xxxxxxxxx> 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