W3C home > Mailing lists > Public > w3c-math-erb@w3.org > April 1996

Parsing of n-ary operators

From: Bruce Smith <bruce@wolfram.com>
Date: Sat, 20 Apr 1996 12:53:07 -0700
Message-Id: <199604201253.6443@uvea.wolfram.com>
To: w3c-math-erb@w3.org
> > [Neil:]
> > The rules you give all seem to be left or right associative.
> > Operators such as '+' and ',' are treated as n-ary 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 n-ary 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 n-ary, but I
don't think the fact that it might be inefficiently internally is
relevant, because we are not specifying the implementation of
HTML-Math, 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 HTML-Math 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.
Received on Saturday, 20 April 1996 16:14:54 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 15 April 2023 17:19:56 UTC