Mail #10745

Back to main page of archive

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

From: Frank Heckenbach
Subject: GPC: daily digest V1 #540
Date: 11 Sep 2004, 23:58:48

Tom Schneider wrote:

> > The compiler internally keeps only one copy of given identifier --
> > the meaning changes according to the scope, but there is only one
> > place to store the spelling. It is natural to take scope rules into
> > account when warning about capitalization, but that requires extra
> > work.
> 
> The compiler already keeps track of scope for each variable.  So
> keeping one copy of an identifier just (apparently) reveals

Again: The warning is about *identifiers* (including keywords
actually), not about *declarations* (and it doesn't claim
otherwise).

> that the
> GPC code is not efficient.

Not really. This way, the capitalization can be checked right after
a word (identifier or keyword) is recognized. When doing it after
distinguishing between keywords and various kinds of declarations,
there would be more places to add the checks.

> In other words, the warning code could
> (should!) use the code already used for tracking the scope.

As I said, I prefer to check the capitalization of identifiers. If
you prefer to check the capitalization of declarations, go ahead and
implement it (optionally). It's free software. But please contact
Waldek before about the details to avoid conflicts with his
qualified identifier changes.

Tom Verhoeff wrote:

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

Because I don't see a "case sensitive interpretation" of Pascal
code.

There may be other Pascal compilers which are case-sensitive, which
is obviously non-standard. Our general attitude to non-standard
compilers is to be at best backwards-compatible, which this warning
surely makes it.

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

Again, Pascal isn't concerned with the capitalization of identifiers
referring to the same declaration any more than it is with that of
identifiers referring to different declarations. If you consider one
thing more "legitimate" than the other, that's your opinion, but
please don't state it as a fact.

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

I don't agree. IMHO, using different cases to distinguish them is
just asking for trouble (because the identifiers are still
equivalent in Pascal). So if you feel you need to distinguish the
names, use different identifiers at all.

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

Interesting idea, to guard against the effects of typos.
Unfortunaly, this will probably need quite some heuristics (and be
more expensive at compile-time).

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

Basically yes. Except that there are many places where an occurrence
(especially an applied occurrence) of an identifier is first
detected. Due to the various standards and dialects, this is often
not possible until deep within the parser.

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

As I stated above, its about identifiers, not declarations. So omit
the defining occurrence part. It's simply, when a name is first
encountered [...]. (E.g. in types, the defining occurrence doesn't
have to be first, but it doesn't matter.)

Frank

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

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