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

Re: scripted operators

From: Ron Whitney <RFW@math.ams.org>
Date: Sun, 21 Apr 1996 12:54:44 -0400 (EDT)
To: soiffer@wolfram.com, w3c-math-erb@w3.org
Message-Id: <830105684.758784.RFW@MATH.AMS.ORG>
Re: the discussion of scripted operators

I'm not sure whether Bruce was speaking tongue-in-cheek or not
on this:

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

I'd say it's not infrequent that people embellish their operators to
parameterize or make variational distinctions.  Precedence parsing
starts with (fortran-like) situations in which the results of bindings
are "terms" elegible for binding with lower precedence operators, but
the natural extension of this to the 1 1/2-dimensional case (symbols
online with possible embellishments around them) is that the
precedence of an operator extends to the entire constellation of
operator and embellishments.  Embellishments include subscripts,
superscripts, pre-scripts, diacritics, font changes, etc.  I believe,
for example, Knuth treats an object such as +_p as a "\mathbin".  I'd
consider \sum in the same light.


Bruce gives a couple of ways to handle scripted operators, then remarks:

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

I'm in agreement on the inconvenience (aka un-naturality).  As to
alternatives, I am looking at the situation as simply a deficiency in
the first cut at precedence parsing.  The logic we're aiming at is
relatively clear, I think.  Our present implementation views the
precedence as applying only to one token and its immediate neighbors,
whereas it should probably extend beyond that after certain operators
are bound.  Can we carry precedence values into the parse tree and
then prune them after parsing is complete?  We'd have to categorize
_, ^, font changes, etc. to indicate that they're absorbed into operators
when bound there.

-Ron
Received on Sunday, 21 April 1996 12:55:35 UTC

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