[Prev][Next][Index][Thread]
Parsing of nary operators

To: w3cmatherb@w3.org

Subject: Parsing of nary operators

From: Bruce Smith <bruce@wolfram.com>

Date: Sat, 20 Apr 1996 12:53:07 0700

From bruce@wolfram.com Sat Apr 20 16: 14:54 1996

MessageId: <199604201253.6443@uvea.wolfram.com>
> > [Neil:]
> > The rules you give all seem to be left or right associative.
> > Operators such as '+' and ',' are treated as nary operators by the symbolic
> > manipulators that I've seen because you can often get expressions that
> > are thousands of "terms" long, and it is very inefficient to build binary
> > trees for those expressions.
> [Dave:]
> Treating + and  as nary rather than binary operators is an
> interesting idea, but can perhaps be handled via the code that
> exports the expressions to say Mathematica or Maple.
I agree with Neil that it is convenient for + to be nary, but I
don't think the fact that it might be inefficiently internally is
relevant, because we are not specifying the implementation of
HTMLMath, only its behavior. Even if we specify that all operators
are left or right associative, nothing prevents an implementation
from optimizing the representation of an addition with lots of terms.
Therefore I agree with Dave that, if the point is to be compatible
with other systems, this can be handled purely by making sure it's
possible to write exporting code which does this transformation
(which will obviously be true since HTMLMath has nothing to say
about the nature of such code).
On the other hand, it might be desirable purely from the point of
view of author convenience to declare some operators as "flat
associative", in order to affect macro processing. For example,
under my proposed method of parsing brackets, you might want the
result of parsing
(a)
not to contain, as a subtree, the results of either
(a
or
a)
since this might affect which macro rules would apply to it. This
allows you to think of paired parentheses as a single operator,
rather than a certain way of nesting two operators.