Hi Kaz, Sorry for the delays on this message, and your others. Thanks for your answer.
> Le 15 sept. 2020 à 10:51, Kaz Kylheku <[email protected]> a écrit : > > On 2020-09-12 08:38, Akim Demaille wrote: >> I'd be happy to read comments about this branch. Too bad --header and >> --html both start with H, there can only be one. Ideas for a short >> option for --html are most welcome. > > "Defines", more often than not, does refer to "preprocessor pound defines", > but not always. It's an informal word that broadly covers interface > definitions of all sorts. > > If we search for the phrase "file contains defines", we can find > citations for that refering to other than preprocessor definitions.\ > > For instance: > > https://www.cse.unr.edu/~miles/compiler/docs/html/ast_8h-source.html > > A comment says "file contains defines of the various types of > astnodes and the fromASTFile function"; these are actually C++ > class declarations. This sounds really weird to me, "definitions" sound much more appropriate. I could not find any dictionary supporting "define" as a noun. > Anyway, the bike-shedding debate between "header" and "defines" > is already settled by the fact that the option already exists > under one of those two names. Well, "defines" is inappropriate, and the fact that the option exists does not legitimate that we keep it mysterious to newcomers. I believe --header/%header to be vastly clearer that --defines/%defines, and with less possible confusion with --define/%define. History mandates backward compatibility, which does not prevent fixes. > "defines" isn't the greatest name, but it's not terrible. Terrible > is, e.g., calling a function "creat" instead of "create". :) :) :) > It pairs with -d, which comes from POSIX. Long and short options > don't have to share the same initial letter, but it's somewhat nice > if they do, and from your remark about "header" and "html", it seems > that you agree. Unfortunately -d is not --defines, because -d does not accept an argument, as per POSIX. That's why -H is not -d. > Adding a synonym and deprecating the old one creates unnecessary > churn that doesn't correspond to any change in functionality or > issue being solved. Which is why we still have "creat". Well, in the present case, I was also aiming at converging to the choice made in byacc, -H. So I'm installing these changes. Cheers!
