@Math package

[Jeff Kingston]

The plan is to replace the @Eq package with Ludovic's @Math package
in the next release of Lout.  @Eq will be available forever for
backward compatibility, but, starting with the next release, only
@Math will be documented (and used) in the User's Guide.

I've been looking through @Math, auditing it in preparation for
its big day out.  It's very well done, congratulations Ludovic!
There are some things I am not happy with, and my plans for those
are as follows.  Comments and suggestions welcome - and remember,
it's getting serious now.  I will wait a week or so for comments,
then revise this plan in the light of them, then implement it and
test it on the User's Guide chapter and see how it goes.


Symbol precedences
------------------

Owing to implementation issues, there are more symbols in
@Math that need precedences than there were in @Eq.  There
are many unusual symbols now needing precedences for which
there are no conventional values to follow, given that the
symbols are rarely used; and there is a problem with the
precedence of sup and sub relative to these symbols.

I propose the following precedence scheme.  Higher numbers
mean higher precedence.  All operators are left associative;
that is, A op B op C means {A op B} op C when the operator
precedences are equal.

   Prec.  Symbol(s)
   ------------------------------------------------------------
   100    big, small, @Base, @Sym, vctr, @Strut
    84    dot, dotdot, hat, tilde, vec, dyad, overbar, underbar
    82    sub, on, ton
    80    sup, supp
    70    sqrt, root, zroot, matrix
    66    atop, below, wideatop, widebelow
    64    Binary operators: times, "*"
    62    Binary operators: div, frac, over
    60    Binary operators: "+", "-", "+-", "-+", setminus
    60    Binary operators: bin, all others
    50    Binary relations: rel and all others
    40    Punctuation: punct, ";", ",", and col
    30    non (see below)
    22    col lcol ccol rcol mcol
    20    row axisrow
   ------------------------------------------------------------

Things that are typically used to build variables have high
precedence (84-80), then come unary operators (70), then binary
operators (66-60), then relations and the rest.  It's unusual to
have binary operators such as sub and sup with higher precedence
than unary operators, but it is convenient in cases like

   sqrt x sub 1

because (I believe) the user thinks of x sub 1 as a variable, not
the result of an operation.  This view is consistent with Knuth's
choice of the notation _ and ^ for subscripts and superscripts.

Ludovic distinguished equality relations from other binary
relations, but I am proposing to give the same precedence to
all binary relations.  A binary relation returns a Boolean
result and it is very rare for its parameters to have Boolean
type, so, in my opinion, the cases where distinct precedences
are needed are too few to justify anything more detailed.


The "non" symbol
----------------

This is not currently satisfactory in @Math.  Its precedence
is part of the problem, but not the whole problem.  I propose
to fix it by adding a fifth style alongside Knuth's "display",
"text", "script", and "scriptscript".  The new style will be
called "nohspace" and will cause all the style-dependent
horizontal spaces to be zero.  Then "non" will be implemented
by switching to this style.  For example,

    @M { non <= }

will look the same as the <= character from the Symbol font:
since "non" will have lower precedence than <=, what you get is

    @Math { non { {} <= {} } }

and the spaces on each side of <= will have zero width
since they will be set in the "nohspace" style.


The "atop" and "wideatop" symbols
---------------------------------

I propose to rename these symbols "above" and "wideabove".  This
would match better with their partners "below" and "widebelow",
and although "atop" is English it is not idiomatic English.


The "not" symbol
----------------

It's not clear how to make "not" work in @Math; I believe that the
current implementation will not work.  So I will get everything else
working, then think about it and probably come up with a fresh
design that does the same thing in a different way.


Jeff