Re: SRFI 105: Curly-infix-expressions

[Aubrey Jaffer <agj@xxxxxxxxxxxx>]

 | From: "David A. Wheeler" <dwheeler@xxxxxxxxxxxx>
 | Date: Sun, 26 Aug 2012 15:05:08 -0400 (EDT)
 | 
 | Aubrey Jaffer:
 | > I like the idea of Curly-infix-expressions; but I think it needs
 | > some adjustments.
 | 
 | Thanks VERY MUCH for commenting, I really appreciate it!
 | 
 | >  Looking at "some examples of c-expressions", there is a
 | > mixture of parentheses and curly braces (and no NFX example).
 | 
 | There are two examples given in the description of nfx:
 | "E.g., {q + r * s} is mapped to (nfx q + r * s), and {q + r . s} is
 | mapped to (nfx q + r . s)."
 | 
 | If you think we should add more examples to the list below, we
 | certainly could.  Examples are easy to add.

I think an examples section should include an example of every
supported syntax.  It's often easier to understand a comprehensive set
of examples than prose.

 | >  Is the syntax { f(x) } not handled?
 | 
 | No, not by curly-infix, and by intent.
 | 
 | I think it makes no sense to handle "f(x)" only inside infix
 | expressions, and not outside them; that is absurdly inconsistent.
 | Scheme is all about being able to do the same thing consistently.
 | If you allow {f(x) + g(x) + 7}, then I believe you should ALSO
 | accept f(x) *outside* curly-infix expressions.

I am unconvinced by that argument.  It would be useful to be able to
paste infix expressions into a program source code without having to
rewrite them.  If I must rewrite them, then I will just rewrite them
into Scheme.

 | > Knowing when to use parentheses with prefix notation versus curly
 | > braces with infix notation requires more detailed syntactic
 | > understanding than should be assumed from parenthephobes.  A
 | > (perhaps additional) specification should be written for
 | > parenthephobes telling them how to program in Scheme using
 | > curly-braces.  It should explicitly state when parentheses with
 | > prefix notation must be used instead of curly-braces.
 | 
 | I don't know what you mean by "parenthophobes" - do you mean
 | someone who doesn't know Scheme?

You wrote:

  "Adding standardized infix support to Scheme would eliminate a
   common complaint by developers who currently choose to use other
   languages."

Parenthophobes are these people who refuse to use Scheme because of
its syntax.  If they are the population SRFI-105 is meant to address,
then they will only be convinced if programs can be written mostly
infix.

If parenthophobes are not the intended beneficiaries, then you should
rewrite your abstract.

 | I'm assuming that only people who already know Scheme will read
 | SRFIs.  Isn't that true?  Who else would read a request for
 | implementation?  I'm asking that seriously - maybe I've
 | misunderstood SRFIs.  If my assumption is false, can you help me
 | understand who these other readers are, so we can write for that
 | audience?

As an implementer I read SRFIs, but that doesn't mean that I am the
beneficiary of every feature.  I have implemented many features I
personally don't use.  Also, many SRFIs are way too technical to be
user documentation.

 | I'm presuming that a tutorial on how to program in Scheme using
 | curly-braces would be part of a tutorial, not part of a SRFI.  I'm
 | not saying tutorials are bad - far from it - just that I think it
 | would go somewhere else.

Okay.

 | > I'm okay with "We think that precedence is overrated."  But I
 | > think that infix-of-more-than-2-arguments is also overrated.
 | > There are many popular infix languages which don't understand:
 | > 
 | >   0 <= x <= n
 | > 
 | > Those infix languages (and SRFI-105) also don't allow what I
 | > really want to write:
 | > 
 | >   0 <= x < n
 | > 
 | > I think eliminating the infix-of-more-than-2-arguments would
 | > further simplify SRFI-105 while only slightly reducing its
 | > utility.
 | 
 | I think that would be a mistake.  Doing so would mean that these
 | would also fail:
 | {a + b + c}
 | {a * b * c}
 | {a - b - c}

So a+b*c must be written {a + {b * c}}.  It's not any more trouble to
write a+b+c as {{a + b} + c}. In fact, it is sometimes desirable to do
so because floating-point addition is not associative.