Re: Happy new Sun (was: man-pages-6.02 released)

[G. Branden Robinson]

Hi Alex,

At 2022-12-22T21:12:39+0100, Alejandro Colomar wrote:
> On 12/22/22 20:39, Alejandro Colomar wrote:
> > Gidday!
> > 
> > I'm proud to announce:
> > 
> >      man-pages-6.02 - manual pages for GNU/Linux

Congratulations!

> I hope this is really my last release in an unsigned long long time[1].

I've already found a typo.  😅

I also think some further revisions to the string copying discussion and
related pages are warranted.  Nothing critical, but if you really want
to start steering hordes of C programmers whose currency is the
Dunning-Krugerrand down new cattle runs, I think you'll need additional
material.

> You can take it as a Christmas present :)  Now, I'm officially waiting
> for groff-1.23 to be released to declare it as a dependency.  Deri
> sent me a present for Christmas, and it would be a much smaller and
> better present if groff 1.23 was out...  just sayin'. :P

I hear you.  I got a present myself this week--a case of coronavirus (my
first).

I will likely push before Christmas Day but I don't expect to squawk to
Bertrand to roll the 1.23.0.rc2 archive by then, for the reasons related
in my status report.

Fortunately my case of COVID is mild and I have nearly recovered.  It
knocked me off my stride for macro programming but I kept on with
corrections to documentation.

> -  Don't release for 2 years or so, until a few months before the
> freeze for Debian trixie.

If it were me I could not see committing to this.  The longer I spend in
a long dev cycle the more I dislike it (even if I'm my own worst enemy
on judging a code base ready for release).  For groff I want to move to
something like a 6-month cycle.

> -  Migrate to MR macros after groff-1.23 is in Debian.[2]
> 
> -  Provide a PDF book of the Linux man-pages (actually, Deri did this;
> I'll just help polish it).

I think these will constitute significant improvements in the everyday
user's man page experience.  We'll see if I'm right.

> [2] We know that the plan of not releasing, so in case I have to
> release, having sufficient groff in Debian should be enough.  Other
> releases either move faster, so they'll also have it, or they should
> read the list of dependencies and/or the release notes before
> upgrading.  Something important like the string issue might make me
> release again with some completely rewritten pages for
> who-knows-what...

I recently put an-ext.tmac on a diet,[1] so people/distributions can
always grab the simplified `MR` definition from there[2] and stuff it
into .../groff/man.local to avoid problems.

I would counsel you to expect the unexpected.

> > -  Rewritten pages for string-copying functions.  These now use
> >     consistent language.  Also added a new string_copying(7) page that
> >     serves as an overview of all such functions, compares them, and
> >     details which is appropriate for which uses.

One of the things I noticed is that the `TH` and the file name fell out
of sync on this one.

> > -  Use _Nullable for documenting which functions accept NULL as a
> >     meaningful value in the function prototypes in the SYNOPSIS.

At long last!  :D

https://www.adacore.com/gems/ada-gem-23

Two of the changes I'd make to Ada are:

1) Make variables read-only by default.  This sounds crazy to old fogeys
   who haven't done multi-thread or multi-core programming.  Rust has
   "let mut" for a reason.  Any piece of storage may have many readers
   XOR one writer.

2) Make access types (pointers) refuse null assignments by default.  So,
   require "nullable" much like what you've documented above for objects
   that contain null references rather than requiring "not null" to
   prohibit them as Ada currently does.

But I know why they didn't go those ways.  Backward compatibility.  Jean
Ichbiah make a huge number of correct calls--especially for the late
1970s when C was a mad dog of a language and not even considered for the
high-integrity applications Ada was--but he didn't call them _all_
right.[3]

Since you have reached a milestone and want some downtime anyway, I will
recommend to you the Ada 83 Rationale document:

http://archive.adaic.com/standards/83rat/html/Welcome.html

I urge you to look past the Pascal-flavored syntax you dislike and see
what other aspects of the language's design and considerations might
appeal to you.

Regards,
Branden

[1] 
https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/an-ext.tmac?id=59efbfc364daee11af9207a3fc79675b6f5bfc25
[2] 
https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/an-ext.tmac?id=59efbfc364daee11af9207a3fc79675b6f5bfc25#n131

[3] While I contrast Ada and C in many respects, they have a somewhat
    sad similarity in that their originators each felt that the language
    rapidly strayed from its principles after standardization.  It
    wasn't Ritchie's death that prevented a 3rd edition of K&R, but his
    objection to the directions taken by C99.  Likewise, Ichbiah, who
    dominated the Ada 83 development committee, famously resigned from
    the one for Ada 95, apparently due to disagreements with fellow
    member (and compiler writer) S. Tucker Taft over the expression of
    OO concepts in the language.  Even having read some of the
    contemporary materials I don't judge myself competent to referee
    that debate.  I get the feeling both sides overestimated the stakes.
    The DoD no longer had the stones to enforce the single-language
    mandate that birthed Ada in the first place; momentum had shifted
    (to less rigorously defined languages with many fewer integrity
    checks at compile- _or_ run-time), and use of the keyword "class"
    versus describing something as a "tagged type" was not going to make
    the difference.  Sure, people were going to grab Java or C++ and use
    them to program the next-generation Grumman KillBots; the former
    group would produce machines that would never make it to deployment
    because the users in the field would still be waiting for widgets to
    render in AWT, and the latter would abandon their contract after
    upgrading a minor support library and being faced with a single
    16KiB compiler error having something to do with templates.

    One of the thing groff did right, even if not by choice, was to
    largely avoid the STL.[4]  Weirdly, I've seen Stepanov credited with
    bringing generics to Ada before selling Stroustroup on them for C++.
    But generics were already in Ada before Stepanov got to it.  While a
    celebrated figure, every time I read Stepanov's stuff I feel the fog
    thickening, not clearing.  Maybe I'm just too dumb to be one of the
    cool kids.

[4] groff uses the preprocessor to abstract types for containers in a
    couple of places,[5] which I don't feel is any better than using the
    dangerously Turing-complete template approach.[6]  I confess I've
    felt tempted to reach for a vector<> a few times.  But since groff
    is not itself a library and its need for generic containers has
    proven limited--only a handful of types are actually used--I
    think it might be a maintainability win to just make ordinary
    classes specialized for the existing cases.[7]

    "In programming, everything we do is a special case of something
    more general -- and often we know it too quickly." -- Alan J. Perlis

    groff even uses its own string type instead of libstd++'s.  I think
    one might argue that it is one of the most successful exemplars of
    the early concept of C++ as "C with classes" ever undertaken.

[5] https://git.savannah.gnu.org/cgit/groff.git/tree/src/include/itable.h
    https://git.savannah.gnu.org/cgit/groff.git/tree/src/include/ptable.h

[6] 
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=e48b38ba086b375f506651351c256fd12eba32fd

[7] Specifically, "ITABLE" is used for only _one_ type, charinfo.

    src/libs/libgroff/nametoindex.cpp:  ITABLE(charinfo) ntable;    // Table 
mapping number to glyph.

    "PTABLE" is used for several.

    src/devices/grotty/tty.cpp:  PTABLE(schar) tty_colors;
    src/libs/libgroff/glyphuni.cpp:PTABLE(glyph_to_unicode) 
glyph_to_unicode_table;
    src/libs/libgroff/make-uniuni:PTABLE(unicode_decompose) 
unicode_decompose_table;
    src/libs/libgroff/nametoindex.cpp:  PTABLE(charinfo) table;     // Table 
mapping name to glyph.
    src/libs/libgroff/uniglyph.cpp:PTABLE(unicode_to_glyph) 
unicode_to_glyph_table;
    src/libs/libgroff/uniuni.cpp:PTABLE(unicode_decompose) 
unicode_decompose_table;
    src/preproc/eqn/lex.cpp:PTABLE(definition) macro_table;
    src/preproc/eqn/text.cpp:PTABLE(char_info) special_char_table;
    src/preproc/pic/lex.cpp:PTABLE(char) macro_table;
    src/preproc/pic/object.cpp:  PTABLE(place) *tbl;
    src/utils/hpftodit/hpuni.cpp:PTABLE(hp_msl_to_unicode) 
hp_msl_to_unicode_table;

    I assume the STL's map<C1, C2> could be used to replace all of
    these.  Iterators are required for at least some; I assume that is
    also straightforward.

signature.asc
Description: PGP signature