Mail #10743

Back to main page of archive

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

From: Tom Verhoeff
Subject: Upper/lower case in identifiers
Date: 11 Sep 2004, 23:07:49

On Sat, Sep 11, 2004 at 08:02:15PM +0200, Frank Heckenbach wrote:
> Waldek Hebisch wrote:
> 
> > I belive that capitalization is meaningfull for people.
> 
> I don't really. In natural language, capitalization is used as a
> help in reading (used differently in different languages), but it
> does not carry meaning itself (e.g., a text written in all-caps
> still has the same meaning).
> 
> > So it is
> > natural that different meanings needs different capitalizations. Of
> > course, some persons may wish warning for re-using an identifier
> > with different meaning (or as compromise, a warning when meaning
> > is different enough to require different capitalization :)). But 
> > IMHO the main use of `-Widentifier-case' is to ensure that standard 
> > (case insensitive) interpretation coincides with case sensitive 
> > one.

Waldek continued to write, but Frank didn't quote this part:

   ...  And for _that_ purpose current behaviour is defective (gives
   spurious warnings).

And I must say, I agree with Waldek.  I think Frank may have misunderstood
Waldek's argument.  Let me try to explain why I feel that current behavior
is not appropriate.

I recently recompiled a project containing some seven thousand lines
of Pascal code distributed over some twenty units.  A couple of years
ago when it was last compiled, gpc didn't have the identifier-case
checking feature.  During the recent recompile, I was overwhelmed with
casing complaints.  Some of them were legitimate: same variable referred
to by different casings.  And I changed the source accordingly.  But many
warnings were completely unexpected for me, and unwarranted.

Consider the following situation.  I have a record type Event,
with a Integer field sc, holding a score.  The identifier sc
is meaningful only within the scope of the record.  It is a local
identifier.  Obviously (to me), all references to this field would
best be done by the spelling sc, and not Sc, or sC, or SC.  The warnings
keep me honest (thank you!).

But I also have a procedure that has a local variable called SC of type
ScoreCard.  Again, this is a local name, only meaningful within the scope
of the procedure.  In fact, it could have been someone else who decided
on that name, someone unaware of the record Event with a field sc.  It is
a local variable in a local name scope.  But gpc warns about the casing
of SC being inconsistent, because it remembers the casing of the field sc.
At least, so it seems to me.

That does not sound right to me.  These are two completely different
name scopes, where different casings may be called for.  I would hope
that the casing is for me to decide, and I don't want a warning from
the compiler.  It is almost as bad as warning me that I have
two procedures that use the same name, such as i, for a local variable.
In fact, it may be even worse to use case-identical names
for entities that are actually very different.  (Think of

var i: Integer; { index in array a } versus
var i: Real; { imaginary part of approximation of smallest zero of f }

But that is a different issue.  You could also warn me when using names
that are nearly equal, such Block and Blok, for different entities.

So, the behavior that I had expected from gpc when it comes to identifier
case checking is that names that refer to the SAME entity (hence,
within the same scope) are checked to have the same casing, warning
me if they are not.  Of course, such identifiers must be equal modulo
case differences, for otherwise they would not refer to the same entity
according to the rules of Pascal.

It is another matter, what it would take to make gpc behave this way.
But I would think, that it should be quite easy to do.  For each
entity, the casing of the defining occurrence is stored.  When a reference
to this entity is encountered (i.e. a name that modulo casing is equal
to the defining occurrence), then the casing is checked against that of
the defining occurrence, and a warning is issued if it is different.

The current implementation seems to be something like: if a name
is encountered in a defining occurrence, its casing is remembered;
and any other name, regardless of scope or entity it refers to, is
checked against that global table to have the same casing.

Waldek, is this what you mean?

	Tom

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

Replies

In reply to

Back to main page of archive

Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.

Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.

This page was created by Crystal 0.999 (Linux 2.4.27/i686).