Shiro Kawai:
> I see those files use full features of 'readable' project.
> Have you ever tried using _only_ the curly-infix subset?
>
> I implemented curly-infix notation in Gauche and stated to give it a try.

That's awesome!  Thanks for being willing to experiment with them.  Experimentation is absolutely vital.

>  And I can't help feeling c-exprs and s-exprs don't mix well.
> To be honest, it's terrible.

Sorry about that.   Let's see if we can figure out what the issue is!

> I started itemizing why they don't mix, but before writing up
> a lenghthy email, I'd better check with you if I'm not doing it wrong.
>
> Here I pasted some code: https://gist.github.com/3502491
> I took exiting code that used some math (and I remember I wished
> to have had infix notation when I wrote them) and converted to C-exprs.

I'm not sure it's *terrible*.  Formats like this look pretty good to me:
    (if {{x < canvas-x0} or {canvas-x1 < x}
         or {y < canvas-y0} or {canvas-y1 < y}}

I think this looks okay too, especially compared to traditional Scheme:
  (lft {{q * u} + {r * w}} {{q * v} + {r * x}}
       {{s * u} + {t * w}} {{s * v} + {t * x}}))
With this one there are certainly two objections one could raise:
1. What about cuddling higher-precedence operators?  That one's easy... just add extra space around "+" if you want to emphasize its lower precedence.
2. Why not have "*" higher precedence than "+", so that fewer {...} would be necessary?  Well, that WOULD be possible.  I've resisted adding precedence for a variety of reasons already documented, but that's not to say it cannot be done.  Most important is widespread adoption.  If we need a few precedence rules - or many! - for widespread adoption, then I think that's what we should do.

I should note that if the infix gets really long (more than 3 lines or more than 6 operators) I tend to switch back to prefix for that one item, with curly-infix used for its parameters.  Programs in other languages often break up infix operations when they get long, for similar reasons. Infix is best when the operators are near each other, but since sooner or later you get down to that point, it's useful.

,,,
> From your code, c-exprs seems to work well when combined with
> n-exprs and t-exprs.  Unless you have a strong reason that
> c-exprs alone is useful (rather than that it is technically
> orthogonal), I now think it may be better to bundle them together.

Well, you're absolutely correct that we tend to use them together.  In particular, I rarely use curly-infix expressions without neoteric-expressions being embedded, so that I can say f(x) instead of (f x).  If that's the point you're making, point taken.  For example, your:

       (if {(abs Fx) < 10e-6} ...

would be written, with neoteric-expressions, as:

       (if {abs(Fx) < 10e-6} ...

So I see three possible directions:
1. Continue with this proposal's current direction, with *just* curly-infix.
2. Add neoteric-expressions inside {...}, recursively.  That would let you use abs(x) as a synonym for (abs x), where you wanted to, and so on.  We didn't do this on the grounds that it's inconsistent to accept f(x) inside curly-infix, and not accept them outside. But it's true that curly-infix isn't standard anyway, so this wouldn't impact any existing standard-compliant program.
3. Change this SRFI to define neoteric-expressions as a datum all by itself.  That would mean that, anywhere you can read a datum you'd accept e(f) as an abbreviation for (e f).

In the longer term, I really want all Schemes to accept neoteric-expressions.  They are *trivial* to implement.  But neoteric-expressions outside curly-infix are, without question, an *ACTUAL* syntax change.  Per the standard, cos(0) should be read as two datums, "cos" and "(0)". Shame on the rare people who *DO* that, and thankfully a pretty-printer can fix this automatically, but I know it happens.

So, I was trying to propose a smaller, self-contained spec that didn't impose *any* change to existing syntax.  I could switch to #2 or #3 easily enough; I have all the material.  What do people think would be the best course?

(I don't know if we can rename SRFIs, but as long as the number stays the same I don't know why we can't.)

--- David A. Wheeler