I said:
> > That said, it *would* be possible to add support for precedence to curly-infix... [but I'm]
> > rather skeptical...

Alan Manuel Gloria:
> NOoooooooooooooooooooo!!...
> I feel somewhat more strongly than David here; I think
> the extra complexity of precedence is much too much
> work for far too little gain, and the current design of "no
> precedence at all" gives the best value for your design
> complexity.

Agree.

> In particular, it's best to remember that one goal is
> continued usability of current idioms.  For example,
> Scheme has classically had char<? and friends, and I
> would guess that it would be idiomatic in Scheme that,
> if I made my own ordinal type, I would define type<?
> and friends.  But if precedence is defined so that for
> example "<" binds tighter than "and", would it work
> for "char<?" also?  How about for my new defined
> procedure that works on my type, "type<?"?  And
> so on.
>
> dwheeler actually made an attempt to support stuff
> like arbitrary "type<?":
>
> http://sourceforge.net/p/readable/wiki/Precedence/

Yes.  A variant of this is also documented in the SRFI-105.

To recap, it's *possible* to support new operators, without declarations, by using conventions that examine symbol spelling. E.G., if the operator isn't in the precedence table, then (1) remove all "-" surrounded by alphanumerics, (2) remove all alphanumerics, and (3) remove all other characters not in the symbol table.  Then consult the precedence table with the new resulting symbol.  For example, "char-ci>?" would have the same precedence level as ">".

Thus, it is *possible* to allow people to create new symbols *and* use them with proper precedence levels, without a registration system.  Which eliminates a lot of bugs.  And you could still write {a + b * c}.

The problem is.... is it actually worth the trouble?!?  The {...} characters only add two more characters for every different operator, and the resulting clarity has its own value. when reading code.  It also makes the specific simpler.

Shiro Kawai:
> I agree that precedence isn't really important at this point.
> Actually, the revised version already have a kind of
> precedence---function applications in the form of neoteric
> expressions have higher precedence than infix ops. It allows
> me to write unary ops & function calls more "clustered" than
> infix ops, hence addresses my original complaint that mere
> c-exprs don't make code readable much.

Reasonable enough.

--- David A. Wheeler