[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 #?
> > 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.:-)
> Sam Mize