Re: [PATCH] Add new files for IELR and canonical LR implementation.

[Joel E. Denny]

Hi Akim,

On Sat, 25 Apr 2009, Akim Demaille wrote:

> Le 21 avr. 09 ? 12:29, Joel E. Denny a ?crit :
> 
> > In wrote many of these files with OO in mind.  As a result, I used
> > customary OO capitalization.  I also chose "__" as my namespace delimiter.
> > If these conventions are too objectionable to others, I'll make some
> > commits later to conform.  Opinions?
> 
> I'm fine with the goal, but I am uncomfortable with the file names: we should
> stick to lower case (LR0 is an exception I meant to solve for a long time).
> The order in which they appear in ls (or in the Makefile if we pay attention
> to sorting them) depends on the locale, which is not a nice feature imho.
> Also, I prefer using a separator in the file names, where the change of case
> plays that role in identifiers.  So I would use annotation-list.* to match
> what we did up to now.

My style has been that, when one main construct is being defined in a 
file, the file name should match that construct's name, so I prefer 
AnnotationList.[hc].  I prefer to choose some descriptive 
lower-case-file-name when defining a collection of related functions, 
classes, or other constructs, so I agree that LR0.[hc] should be lr0.[hc].  
It's similar to the distinction between a proper noun and common noun in 
English and other Romance languages.  However, I've never been affected 
much by the locale issue, so I don't know what to say about that.

> Some names were "mangled" (e.g., symlist) thinking
> about broken file-systems that have only 8+3 relevant characters in their file
> names.  I have no idea whether this constraint should still be observed.

I see that autoconf has several commands that do not follow this 
convention: autoheader, autoreconf, autoupdate.  coreutils and gnulib have 
some source files that break the convention as well.  Does bison have 
different needs?

> A simple underscore seems enough to me, like in some other files.  Also, it
> seems that some member functions have mixed case and others do not depending
> on their visibility (private/public).

I use Class__memberFunction for a function whose first argument is an 
instance of Class.  I use Class__static_function for a function that would 
normally be declared static in a C++ class because it does not operate on 
an existing instance.  Replacing "__" with "::", that matches the 
convention I learned for C++.  I prefer "__" instead of "_" to delimit 
namespaces because "_" separates words.

Throughout all the file name and symbol name conventions I describe above, 
notice that I use lower[-_]case when code is more like traditional C, and 
I use [cC]amelCase when code is more object-oriented.

I declare private functions static in a .c file.

> I stick to lower case for C++ member
> functions, as is the case in STL and Boost (though, I agree, they also use
> lower case for class names), and use a trailing underscore to mark private
> attributes.

I learned that lower_case is the convention for C++ builtin symbols or 
standard library symbols but that the conventions I described above are 
more appropriate for user code like ours.  However, I suppose Bison's C++ 
skeleton could be thought of as a standard library for Bison's users.

Thanks for responding to this.  Let me know what you think.