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

[Akim Demaille]

Le 28 avr. 09 à 18:27, Joel E. Denny a écrit :

Hi Joel,

> 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 understand the original motivation, of course.

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

Will do then.

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

I know several peope who name their directories LikeThis, and their  
files like-this, so that a simple ls displays directories and files  
separately.

When listing files in Makefile.am, I put them one per line (or  
possibly the whole foo.* family), and M-x sort-lines them.  But on  
some collaborative project I work on we don't all have the same locale  
and the collating order differs.

When I'm looking for a word in a dictionary, I don't expect the case  
to be relevant.  So really, I still think it is disturbing to have  
different types of file names.

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

Yes, it does: these files are still different in 8.3 (I was thinking  
about symtab and symlist in bison).  For years, this was a TODO in  
Automake:

> Handle dist-zoo.  Generally add more DOS support.  Maybe run "doschk"
> (why isn't this merged with "pathchk"?) when doing a dist.  Do
> whatever else Fran<E7>ois says here...

But elsewhere (in the documentation), one can read:

> Nowadays it is no longer worth worrying about the 8.3
> limits of DOS file systems.


so forget about this.

>  coreutils and gnulib have
> some source files that break the convention as well.  Does bison have
> different needs?

No, certainly not.


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

OK.

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

That's why I moved from Location (originally) to location.

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

I'm fine with the identifiers within the files, but I am more troubled  
with the file names.  Especially because they are so few that they are  
a very visible exception.  Unless you have bigger plans :)