Hi, On 8/14/22 21:43, DJ Chase wrote:
True; prescriptive standards can certainly make some things worse. As a further example, ISO 8601 sucks. I mean, its core specification is great, but there are so many different ways that are allowed that the full standard is almost completely unparseable. It also uses a slash between the start and end times of a period instead of something sensible, like, I don’t know, an en-dash! Which means that periods can be written with a slash (because that’s the standard) but also with an en-dash (because that’s how ranges work in English), but also that one can’t properly write a period in a file name or URI. Still, though, I think descriptive standards can be net-positive. The POSIX shell utilities comes to mind. Sure, they certainly have some issues, but because it’s a trailing standard, implementers are free to fix them. Do you think that a descriptive/trailing standard could be beneficial or would you still say that it could mostly hinder *roff implementations?
Well, a standard that truly recognizes the authority of implementations to drive the language and doesn't do anything else but describe the best already-implemented ways to achive things is a good thing. It can't hinder future implementations, because it doesn't have the power to drive the future of the language, only describes the past.
POSIX C has been doing good in that; much better than ISO C.I don't understand how POSIX works internally, though. If some entity can fund (and is interested in) such a standardization process, it could bring some good. But yeah, it will likely be very costly in time and money. Worth it? I don't know.
But we can achieve something very similar by documenting the differences between known roff alternatives somewhere. And that's likely to be much easier.
In the Linux man-pages we document when a function is in ISO C or in POSIX, but also when it's not standardized but present in other Unix systems (so that it has some degree of portability), or when it is Linux-only. Maybe having something similar in groff's manual pages would be effective.
For example, for .MR, we were discussing that probably it would be good to add a note like "(since groff 1.23.0)" and maybe it could also state which other roff (or mandoc) implementations support it.
Cheers, Alex -- Alejandro Colomar <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
