Re: [TUHS] Re: symbols in eqnchar

[G. Branden Robinson]

Hi Damian,

At 2023-07-05T23:57:21+1000, Damian McGuckin wrote:
> > I think such a thing would probably be typed once per document, via
> > an "include" primitive, rather than every time eqn is run.  (And
> > even if "include" didn't exist, I figure that most serious *roff
> > documents are generated via Makefiles, not by ad hoc command line
> > entry.)
> 
> As far as I can tell, the EQN
> 
>       include
> 
> does not honour the GROFF_TMAC_PATH search path. I think I would to see it
> default to
> 
>       . : the site-tmac directory : the standard tmac directory
> 
> but that might be a dumb idea. What does anybody else think?

I think it's a pretty good idea.  While eqn definitions aren't *roff
macro files, they're pretty close.

Even if we don't re-use GROFF_TMAC_PATH for this purpose, we could add
an `-I` option to GNU eqn and have groff(1) pass any `-I` option it is
given along to eqn.  Precedent comes from groff(1):

    -I dir
        Works as troff's option (see below), but also implies -g and -s.
        It is passed to soelim(1) and the output driver, and grn is
        passed an -M option with dir as its argument.

> Note that using an 'include' of a global file is problematic because
> there is no way to embed comments in that file as it must be solely
> EQN code.

That's a tougher problem.  There is no comment syntax for eqn, and it
might be too late to arrogate an ASCII punctuation character to use as a
comment character, given the conventions grown up around delimiters.
Surely a non-trivial number of people have input like

  define # blah #

With that off the table,

We could consider making the inclusion parser more strict.  It already
ignores lines that start with ".EQ" and ".EN".  We could make it use the
same rules that input reading already applies, ignoring everything
_except_ lines between ".EQ" and ".EN".

A user could then comment the file with troff comments outside of
.EQ/.EN (which already don't work within eqn input), or even with plain
text.

This would be a disruptive change, but to a feature that is already a
GNU extension and one that is a bit hard to use because of the
inflexibility of file name resolution, as you noted above.

To aid users to make the transition, we could have GNU eqn throw a
warning diagnostic if it finished reading an `include`d file without
finding any eqn input in it.

The result might be a net win.

> I do mention the longer names that (4 of us thought) are preferable in
> the body of the Guide and cross reference the EQNCHAR name. That said,
> that preferable longer name might not be what others think. The 4 of
> us are all Aussies and mostly engineers so others might think
> otherwise. Feedback needed there.

I may be on the side of the engineers rather than the Unix/OS nerds.
I've spoken before of my approval of Ada as a programming language.  I
also like Fortran's approach to keyword spelling--complete, meaningful
English words.  Any code written for utilitarian purposes (as opposed to
mental calisthenics) is read many more times than it is written.  And
programming is not a licensed discipline like law or medicine, with its
practice legally restricted to white-coated, security-cleared men
standing on raised floors, helping Edward Teller maximize yields to more
efficiently blow up the world.

Instead programming is practiced by people in many disciplines to aid
them in solving problems, often on an occasional basis, and thus should
be accessible to amphibians, and not marine life alone.  And insofar as
accessibility requirements apply to what are nowadays termed
"cyber-physical systems", they go double for manuscript preparation.

> I note that some people often abbreviate the "there exists" symbol,
> the reverse E, to the shorter form "exists" in their own code. So
> strictly correct long names will not suite everybody.
> 
> Also, what is an equals sign with a dot over it used for?

As far as I know it is another way to express approximation.  (I have
seen it used this way, and employed it myself for that purpose in
TeX-based coursework without drawing a red pen for my usage, but then I
was a lowly undergraduate and it's possible mathematical fluency was not
expected of me even though I turned in my assignments typeset instead of
hand-written.)  Cajori's _History of Mathematical Notations_, despite
its seeming comprehensiveness, covers this subject only briefly, and
mentions dot-over-equals not at all, as far as I can tell.  (See
attachments.)

Online sources claim that it can be a notation for "defined as".[1]

My conjecture is that its use is not standardized and its meaning should
be presented before it is employed.  That does make it harder for us to
supply a predefined macro name that gives it a mellifluous name for
reading aloud.

Regards,
Branden

[1] 
https://www.quora.com/What-does-this-mathematical-symbol-mean-I-think-it-is-called-Delta-Equal-To

cajori_nearly_equal_1.png
Description: PNG image

cajori_nearly_equal_2.png
Description: PNG image

cajori_nearly_equal_3.png
Description: PNG image

signature.asc
Description: PGP signature