[said Sam to Mike to Tucker to Rick]

> The other technical issues seem pretty simple to solve:

Sure, if you write the rules to allow only simple cases.
I'm going to play devil's advocate with you here. (Hey,
I'm a prof, that's my job!:-))
>
> > Allowing arbitrary operator symbols would require the writer to
> > specify, somehow, what the precedence of the new operator was.
>
> They're all user-precedence, below the normal operators.

Which means they are all equal precedence? That's very restrictive -
why can;t I write A # B % C and specify that it means A # (B % C),
that is, % takes precedence over #?
>
> >This
> > would, in turn, require some new syntax to specify it,
>
> If you declare a one- or two-argument function and the name is in
> quotes, it's an infix function.

Sure, fine as far as you go. But after all, if C can have ternary
operators, why not Ada? If I can write X ? Y : Z in C and have
? and : be part of the same operator, and you won;t let me do it
in Ada, forget Ada!
>
> >and would also
> > require compilers to support arbitrarily large and complex precedence
> > tables.
>
> Just one more table (user-level), which would be handled much like any
> table of user-defined identifiers.  (This may be where my inexperience
> in compiler design weakens my argument.  I don't know how much modern
> compilers depend on having static tables for syntax analysis.)

But your extensions are so minimal that they wouldn;t make much
difference in the real extensibility of the language, and we'd
pay a price in readability. Insufficiently high payoff for the effort.:-)
>
[snip]

> Sam Mize
>
Mike