Re: [TUHS] Re: symbols in eqnchar

[G. Branden Robinson]

Hi Damian,

At 2023-07-05T14:25:01+1000, Damian McGuckin wrote:
> Should I advocate for the 'eqnchar' symbols to be automatically
> included at 'eqn' startup. After all, namespace pollution for those
> who need none of those symbols is a bad thing.

I think not, and in fact I have a notion rumbling around in my head to
move many/all of the predefined macros into "eqnrc" to make it more
straightforward for people to (1) see how they're defined; (2) replace
them; and (3) develop their own dialects of eqn if they want to.

> But, providing an updated list of such definitions in a file name like
> 
>       /usr/local/share/groff/site-tmac/eqnchar
> 
> is a long file name.

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

> Should I include better definitions for things like
> 
>       therefore instead of thf?
> 
> and so on and
> 
>       exists instead of oppE?

The longer names would be my preference.  One of the selling points of
eqn is that it is supposed to resemble mathematical language as spoken
by a trained lecturer.  Abbreviations don't serve that goal.  Let users
come up with their own abbreviations.  A large and healthy community
will tend to accrete a set of accepted, useful ones to the extend that
doing so facilitates usage.[1]

Regards,
Branden

[1] That is also how Unix command and C library symbol names should have
    been handled in the 1970s.  But the file system was limited to 14
    character names, externally visible symbols in object code to 6 (by
    the linker), and the shell didn't have user-defined functions.  One
    used to hear from people about how the terseness arising from these
    limitations was responsible for Unix's elegance and/or success.
    Except insofar as they enabled the system to fit into core on a
    PDP-11/20, I think those are false beliefs, and memory limitations
    no longer justified these limits by 1980 or so, as can be seen in
    BSD Unix.[2]

[2] I think user-defined shell functions came a bit later, to be honest,
    but I'm not sure when, and TTBOMK BSD doesn't warrant credit for
    them since csh lacks them.  Certainly rc and ksh had them by the
    mid-1980s.  As I understand it, memory was not the limitation in
    adding them to the Bourne shell; rather, its maintenance was made
    difficult, partly by Bourne's ALGOL-inspired coding style, but also
    by the many optimizations and hacks demanded of Bourne's original
    implementations by his colleagues at the Labs, who insisted that his
    shell not run more slowly than Mashey's.

    https://www.in-ulm.de/~mascheck/bourne/segv.html

signature.asc
Description: PGP signature