[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Akim Demaille
Subject: Re: [PATCH] Add new files for IELR and canonical LR implementation.
Date: Sun, 10 May 2009 22:08:51 +0200

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

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


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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]