eqn definitions (was: Fwd: Re: suspected `eqn' bug.)

[G. Branden Robinson]

Hi, Tadziu!

At 2022-07-01T01:10:16+0200, Tadziu Hoffmann wrote:
[I wrote]:
> > This appears to be because "PI" is a magic token in eqn(1),
> > preferentially interpreted even in this context as a shorthand
> > for the capital Greek pi symbol; it is therefore replaced with
> > a special character escape sequence to access the
> > corresponding glyph, which is `\(*P`.
> > How do we cope with this problem?
> 
> Quoting the argument works:
> 
>   gfont "PI"
> 
> It seems that the parser does not make an exception for eqn
> control commands, at least in this case, so "PI" remains PI
> and is not replaced by the Greek uppercase pi, just like in
> 
>   "PI" + "pi" != PI + pi

Yes.  This made a lot more sense once I looked at the sources.  The fact
that our eqn(1) man page talked about macros (in the eqn language, not
*roff) while Kernighan & Cherry's "Typesetting Mathematics" never did
led me to assume there more kinds of syntactical objects in eqn than
there really are.

As penance for my cluelessness I deeply perused that document today.  I
reckon I'll see if my expertise grows appropriately.

One thing that leaped out at me is that many definitions appear to be
prepared in eqn's source that could just as easily be done in eqnrc.
See the statically initialized arrays starting at
<https://git.savannah.gnu.org/cgit/groff.git/tree/src/preproc/eqn/lex.cpp#n126>.

I get the feeling that relocating such definitions thus would pay a few
benefits.

1.  We wouldn't (necessarily) have to list them again in any
    documentation--or at least not the man page--since eqnrc is present
    in all installations.
2.  They will show eqn users how to do various things without C escape
    syntax muddying the waters.
3.  They'll loosen the coupling between eqn-the-language and this
    convenient but arbitrary support feature.  Architecturally, this
    appeals to me.

A few definitions are already present in eqnrc, whether for
device-specific support or to make some definitions "simple" (i.e.,
their macros fail to expand if they're given arguments).  Having the
complete eqn dictionary--apart from truly intrinsic language operators
or procedures like "over" and "gfont"--available to all users, even
those who don't access groff's source code, for study in the relevant
implementation language seems like a win to me.

Regards,
Branden

signature.asc
Description: PGP signature