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.

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

Now obviously it WOULD be useful to handle the form f(x).  We have a separate notation, and a SRFI being developed for it, called "neoteric-expressions".  Neoteric-expressions start with curly-infix, and *add* the ability to use f(...) as an abbreviation for (f ...) *anywhere*, both inside and outside curly-infix expressions.  That way, you can get f(x) without being inconsistent.

We certainly *could* add support for neoteric expressions inside {...}, though if we do, I think it should recurse so that {f(y(z))} would work.

But we need to be careful.  There are a number of "infix" notations for Lisp that I think make a terrible mistake: they create a completely different, incompatible syntax.  The result is that they don't work at all with macros, quoting, and so on.  They also aren't consistent with the rest of the language.  The point of curly-infix is to be as "Lispy" as possible, so that the parameters work "just like everywhere else".  E.G., `{,b + c} should "just work".

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

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?

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.

> You give a good justification for why precedence isn't supported, yet
> the specification doesn't enforce this by requiring an error be
> signaled for ambiguous expressions.

Correct.  The idea is that if you want precedence, you can define a macro "nfx" to implement it.

>  Furthermore, the draft allows
> implementations to implement any precedence behavior using NFX.

True.  That may be too generous.  My theory is that someday, there might be a precedence system, but that would be a *separate* SRFI, and I don't want to tell people that they "no longer comply" because there's some future spec.

We could simply say that implementations MUST insert nfx.

>  If SRFI-105 is going to be an alternate syntax for Scheme, it should
> force uniformity among supporting implementations.  Less radical than
> not allowing ambiguous expressions would be having left-associative be
> the default precedence.

I think that would be far too confusing.  People would be shocked if:
{3 + 4 * 5}
silently computed 35.  Better to insert "nfx" and deal with it.

Also, if you allowed left-to-right now, that would *PREVENT* anyone from adding a precedence system in the future.  I think that would reduce acceptance, not improve it.

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

It would be *possible* to devise a precedence system that builds on curly-infix, and one that even allowed {0 <= x < n}.  I've even devised a draft one, primarily to make sure that curly-infix could (in the future) be extended later for precedence.  And yes, curly-infix can easily be extended for precedence in the future if that's important.

--- David A. Wheeler