Hi Akim, Sorry for the very late reply to this.
On Mon, 10 May 2010, Akim Demaille wrote: > I would like to document %define location_type (and some more tests, and > some more NEWS), but the name is poor. I guess we should make it > something like %define api.location.type. But then, I feel that I was > wrong with api.tokens.prefix. Joel, is the name api.location.type > appropriate? Should I move the latter to api.token.prefix? I had this idea that we should always use plural when naming something of which there can be more than one occurrence. In that case, we'd have: api.tokens.prefix api.locations.type lr.keep-unreachable-states lr.default-reductions Of course, when we count occurrences, we have to count per something. The parent namespace identifies that something. For example, in the case of api.tokens.prefix, there can be multiple tokens in the API, and there can be one prefix for all those tokens. For top-level namespaces (such as api or lr), I suppose we can just stick with singular. You seem to want to create the exception that we should use singular for a name that is a single word. Then we'd have: api.token.prefix api.location.type lr.keep-unreachable-states lr.default-reductions Maybe that follows accepted conventions better than my idea. I don't know, but it seems inconsistent to me. Or do you prefer the following? api.token.prefix api.location.type lr.keep-unreachable-state lr.default-reduction Then the value of "all" for lr.default-reduction says to me that there's one default reduction and that the user is requesting all of it. Should we rename "all" to "every"? I recall that Paul Eggert usually has good ideas for this sort of issue. Paul, what do you think? Do you know of a common convention we could adopt here? (By the way, welcome back.)
