Re: @Math package

[Ludovic Courtès]

Hi,

address@hidden (Jeff Kingston) writes:

> 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.

Thanks for taking care of it!

>     64    Binary operators: times, "*"
>     62    Binary operators: div, frac, over

address@hidden' in 3.36 gives `over' and friends a higher precedence than `*',
but I can't remember of any good reasons to do this.

>     60    Binary operators: "+", "-", "+-", "-+", setminus
>     60    Binary operators: bin, all others

Is it intentional that both have 60 here?

> 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.

Right.

> 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.

Agreed.

> 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.

That seems to be a reasonable approach.

(That said, I'm wondering if `non' is very useful, and I don't find its
name very descriptive.)

> 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.

It's the same definition as in `eq'.  What makes you think it "won't
work"?

Besides, overlapping a slash with any kind of relational symbol is
probably questionable, typographically-wise.

Thanks,
Ludo'.