Re: scripted operators

> Also, I didn't see anything in your test grammar for dealing with scripted
> operators.  Eg, suppose you define:
> prefix operator "sum" (or use '-' in place of 'sum' in the example below).
> infix operator "cross" (or some other operator with precedence higher than
>     times but less than prefix minus)
> 
> Then
> -n cross sum _ i i
> 
> should group as
> {-{n cross {{sum _ i} i}}}
> 
> The interesting thing here is that 'sum _ i' must reduce to a prefix operator
> with the same precedence as sum, and then this must grab the 'i' operand
> as opposed to treating the operand/operand conflict (...i i) as multiplication.

I don't see a good way to do this at all, since

(1) it forces the parser
to wait for the results of further processing of an expression it just
parsed before continuing,

(2) the subscript operator _ applies to terms, not other operators.

I suggest not handling this case of scripted operators by precedence
parsing at all. They can still be handled by authors in either of
two ways:

- explicitly bracketing subexpressions with {}s, and forcing certain
operators to be treated as terms (using my proposed <me>...</me>
tags) so they can be subscripted, and forcing the resulting term
to be treated as an operator (using <mo>...</mo> tags);

or (the one I, as an author, would usually prefer to use),

- letting the author declare an infix operator "sumn" with the same
precedence as "sum", and define a macro which rewrites the resulting
parsed expression (after precedences have already had their effect),
replacing "sumn" with the appropriate scripted expression. (Note
that this has to be done once for each different subscript being
used.)

I admit that neither method is as convenient as one would like. Do
you see any alternative?