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

Re: SRFI 105: Curly-infix-expressions

 | 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

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

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.


 | > 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.