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

Re: SRFI 105: Curly-infix-expressions

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.