Re: on math-specific issues (repost)

At 4:11 PM 7/4/96, Ka-Ping Yee wrote [excerpted]:


>------------------------------------------------------------ integrals
>[028] Ron Whitney writes:
>> Dave proposes something on the order of
>> 
>>   integral from ... to ... of ... \d x
>> 
>> for an "ordinary" integral.
>
>While this works, i have a little trouble with the notion that
>"integral" is just a symbol which gets "operated on" by "from"
>and "to".  Integration is an operation in itself; the limits are
>attributes to the operation, and the expression is the main
>argument of the operation.  I do agree that it is the easiest
>to read of the representations i have seen so far, but i think
>it's important to separate the namespace of operations and
>identifiers.  I've seen "from" and "to" used as identifiers.

Probably this is already clear, but just to be sure: I (and Neil) agree
wholeheartedly with these comments; in the Wolfram proposal (as well as
in Mathematica), the integral sign and the "d" are both operators.
There is an example of their use in my proposal outline. And we do also
separate the namespaces of identifiers and extended characters, and use
nonrendering extended characters for "named operators".


>----------------------------------------------- meaning of a subscript
>Subscripts have two distinct purposes that i know.
>
>So far i haven't seen any mention of this distinction on the list,
>but subscripts are sometimes used as numerical indices -- where they
>could themselves be expressions -- and sometimes used as qualifiers,
>where their purpose is just to distinguish identifiers.  We need both
>to convey the expression accurately.

This is one of the distinctions that is needed by a semantic system
but not by a notational one.

In our proposal, if an author wanted to specify the semantics of
this, they would need to use one of the extension mechanisms
which have been discussed, but not yet proposed in detail, and
either use new operators for index-subscripting and qualifier-
subscripting, or specify in the "semantic context" some rules for
determining which of these is intended by each use of subscripting
(possibly based on "identifier type" or on which specific
identifier was being used).


>------------------------------------------------ labelling expressions
>So far i haven't seen much talk of labelling.
>
>We're also going to need a compound which attaches a label to part
>of an expression (that might get rendered, for instance, like the
>\overbrace or \underbrace from TeX).

Our proposal has overscripts and underscripts, which were not
described in my outline letter, though the syntax was mentioned.
These can be used to put horizontally-stretchy characters
underneath expressions, as "labels" or for any other intended
meaning.

>We might use a similar compound to produce a compacted expression
>with subexpressions shown only as their labels until the user
>requests that they be expanded (like AsTeR's subexpression
>substitution, or like the alternating link macro added by IBM's
>techexplorer).

This has been much discussed by phone, and to some extent in the list,
and I think we will add such a compound to the next draft of our
proposal. However, it will be only a suggestion (hint) to the renderer.
(Raman's system automatically generates the names and also
automatically decides where collapsing should occur, and I would
imagine that the consistency of "feel" thus achieved, compared to the
use of hints by authors, is probably desirable.)

We may separate the features of being able to suggest a "name" for a
subexpression (to be used if it is collapsed, or perhaps for other
purposes by the renderer), and being able to suggest that it be
collapsible. In any case, whether the renderer initially shows an
expression as collapsed will be a user (not author) style preference.

Also, as far as HTML-Math knows, this will have nothing to do with the
first kind of labelling that you mentioned, e.g. using underbraces. Of
course, a renderer could decide to show labelled expressions that way.


>-------------------------------------------------- invisible operators
>[089] Bruce Smith writes:
>> The rule for deciding which one is inserted is precisely this: an
>> invisible function application operator is inserted if and only if
>> its left operand would be an identifier or a scripted identifier,
>> and the token to its right is a left bracket operator (such as a
>> left parentheses).

[I should point out that I defined "scripted identifier" later in that
paragraph to include wrapping with "non-directly-rendering schemas
(e.g. font changes)".]

>Correct me if i am wrong, but simply checking for identifiers doesn't
>seem to be enough.  I tried such a scheme too, and it worked fine
>until i realized that this would disallow the use of operations on
>functions, such as in the case of a function composition operator
>(f 'compose g)(x) or functions of functions, as in f(g)(x).  

It doesn't disallow them, it only forces authors to mention the
function-application operation explicitly in these cases.

>So in MINSE, this problem is solved by requiring an explicit
>multiplication operator.  This also alleviates the ambiguity between
>multiple-character operands and multiplication of single-character
>operands.  Function application is parsed by looking for an element
>before a parenthesized element (in effect, treating the
>left-parenthesis as though it were an infix operator).

So our systems are somewhat similar -- both allow explicit operators
or infer them, though MINSE is simpler (if I understand it correctly)
in having only multiplication as an explicit operator and only
function application as an inferred operator.

The reason we have the complexity we do is to allow authors to avoid
specifying this in most common cases. Admittedly we don't handle all
of them (especially function composition), thus we provide the "escape"
of specifying the operation explicitly. MINSE has the advantage of a
simpler rule for inferring the operator, but the disadvantage that
an extremely common operator to be left out of math must always be
explicit.

If you can think of a way our inference rule can be improved, e.g.
to handle function composition, while still handling the commonest
cases the way it does now, I'd be very interested in hearing that.
(And I'd eagerly consider modifying our proposal to use it.)

- Bruce