Re: %define location_type

[Joel E. Denny]

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