Re: specifying precedences

>5. I hope that in the end the precedence values have a more
>abstract front-end for users to interact with.  Hard-coding
>something like "400" for a precedence value may well lead to
>trouble (i.e. rigidity) down the road.  How many different values
>are there at the moment?

In Mathematica's character set there are on the order of 80
precedence levels.

>I would think that extensibility would
>better be achieved by ordering a new precedence abstractly within
>existing precedences rather than assigning an absolute value.
>This would also get over the (perhaps not-terribly-worrisome)
>discreteness characteristic of the natural number ording.  It
>seems better to use a dense ordering as a basis than a discrete
>ordering.

I think you're right that, if precedences have specific values
at all (rather than being an abstract ordering), the set of
values should be dense, so that it's always possible to add
new operators between any existing ones. This is not important
for a fixed precedence table but is very desirable once we
allow people to add new operators.

So I'll amend this part of the proposal in some way.

My guess is that the simplest choice, all things considered,
is to allow precedences to be arbitrary precision real numbers
specified as an optionally signed integer perhaps followed by a
decimal point and some more digits. (These would have to be compared
more or less as strings in the renderer code (so as to be arbitrary
precision and thus form a truly dense set), which makes the code
a bit more complex than for integral precedence values -- for
good performance it would have to compute integral precedence values
which served just as well.)

Another possibility, as you suggest, is to specify only an ordering
for the precedences of operators, not absolute values. The reason
I chose the absolute precedence approach was that it was not clear
to me how feasible it would be to design a simple-enough format, for both
the standard dictionary and (in the future) for incrementally added
operators, which allowed specifications of the total ordering of the
left and right precedences of all the operators.

One approach would be:

For incremental additions of operators, have some notation for
their precedence values which consists of an optional prefix operator
for "just above" or "just below" (which makes a new precedence value)
followed by a notation for "the left prec of this operator"
or "the right prec of this operator" (or just the operator, and use
the same side as the prec you're defining). (One complex issue --
should "just above" skip precedence values that are really near the
given one, but not equal to it, due to their use to implement the
associativity of the operator they're already attached to?)

For the standard dictionary, allow the bulk of the operators
(almost all of which have the same left and right precedence)
to be specified by listing them in order of precedence,
then allow a few to be added using the general mechanism.

If someone will propose detailed version of the notations needed
for this, I think we should seriously consider using it, instead of
absolute numerical precedence values. I did not want to take the
time myself to write up such a proposal, since I thought absolute
numerical precedence values were well-understood and adequate.