Mail #10761

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 #541
Date: 13 Sep 2004, 19:42:38

Tom Schneider wrote:

> Frank Heckenbach wrote:
> 
> > BTW, calling it a bug is a bit strange, anyway. In Pascal, even
> > occurrences of an identifier referring to the same declaration can
> > have different capitalizations; the same applies to different
> > declarations (e.g., local vs. global) as well. Therefore, all this
> > is an optional warning, not an error.
> 
> It is not a Pascal bug in the sense that the program will still
> compile correctly since Pascal accepts any capitalization. However, it
> is a bug in GPC in the sense that the compiler treats the variables
> inconsistently.

It's one thing to disagree in a discussion, but if you keep
offending me (by calling an intentional decision which is not
contrary to any standard a "bug" or not "legitimate"), I'll quit
this discussion and might killfile you. Last warning (definitely no
pun intended)!

(Again, it is a warning about *identifiers*, not about
*declarations* (variables etc.).)

> Especially in German it means that the word is
> either the beginning of a sentence or a noun, right?  Are there cases
> in German - I bet you could find or make some! - where the meaning of
> the sentence changes dramatically if you were to change the case of a
> noun?

Yes, and there are cases (in German and probably in other languages)
where even the same sentence with the same capitalization can have
different meanings. Natural languages are (slightly) ambiguous.
Formal languages are meant to be an improvement (in this aspect), so
such comparisons are void.

> FOR EXAMPLE.  I am a molecular biologist, so the letters A, C, G and T
> have great significance.  In some programs I might want to capitalize
> these to fit the convention in molecular biology.  But in another
> piece of the code I may decide that 'c' is to be the name of a
> character read in.

In your situation, I *really* wouldn't *ever* use `c' for such a
variable, in order to avoid confusion, cf. the `GotHere' example
below.

> Irrelevant
> warnings that I can't get rid of make it MUCH more difficult to locate
> the important warnings!

In general I agree with this statement. But it doesn't apply here.

> Worse, if one of my students decides to write code, I have to worry
> about what they have done in modules that I'm NOT working on.  Suppose
> I ask them to write a procedure for me and they pick a "non-standard"
> capitalization that doesn't match something I'm doing?

Use `-Widentifier-case-local'.

> Saying that I should use external files is NOT A SOLUTION because
> there is no standard that all compliers use for reading such files and
> if I used that approach,

If you use "external files" to mean modules, and "modules" (above)
to mean include files or similar, it may help to use more standard
terminology.

> This is why the GPC convention of capitalizing the first letter
> of an identifier when giving errors or warnings is painful.

Where does GPC still do so?

> Frank Heckenbach wrote:
> > > 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.
> 
> You of course know the compiler guts and I don't.  But what you are
> saying implies that the mechanisms for capitalization checking and
> scope checking are separated.  In that sense the compiler appears not
> to be efficient.

Lexing and parsing are separated, as in every other compiler and
interpreter in the world. Or what do you mean???

> Frank Heckenbach wrote:
> > 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.
> 
> If there were (theoretically) a compiler that understood case with
> scope correctly, then this current design would not be compatible.

There are such compilers, e.g., every C compiler in the world.
I don't recall that we plan to be compatible to them. Such a
compiler obviously wouldn't be a Pascal compiler.

> Frank Heckenbach wrote:
> > > 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.
> 
> No, he means that some of the warnings were appropriate and some were
> not, according to the scope of the variable.  The inappropriate ones
> get in the way of finding the legitimate ones.

So you substitute "legitimate" for "appropriate". Playing with
words, nothing more. Next time, you might want to add "IMHO" or
something, otherwise I see no reason to reply to unfounded claims.

> Frank Heckenbach wrote:
> > Well, I was about to write "these comparisons go too far" before I
> > read this paragraph, but now it's really too much! Emotions in a
> > Pascal program, eh? ;-)
> 
> EMOTIONS ARE USED IN TEXT!  (SorryForYelling.)  Haven't you ever
> embedded something like that into your code?

In comments perhaps. If you do this in your program code regularly,
you might want to get professional help, sorry.

> Frank Heckenbach wrote:
> > Let's stick to Pascal based arguments, perhaps?
> 
> This is NOT a "Pascal" issue.  It is a GPC issue.

Incidentally the P in GPC stands for Pascal, in case you didn't
know.

> I think that we all
> agre that in the language Pascal itself, case is not relevant.  The
> issue here is about programmers and what happens when they attempt to
> use capitalization to help them understand AND DOCUMENT the code
> better.  If the capitalization does not follow the scope rules of the
> identifiers, then the programmer will OFTEN have trouble.

If the assumptions of the programmer do not match the behaviour of
the compiler, then the programmer will also have trouble (perhaps
not as often, but sometimes in more tricky ways, see the example
below).

My preferred solution is to avoid both, by using capitalization (for
declarations if you will) consistently *and* avoiding different
declarations having the same identifier with different
capitalization. IMHO that's the only way to pretend to be
case-sensitive without getting bitten. It's a little restriction,
compared to a real case-sensitive language, but one I'd rather
accept than getting surprising bugs.

> Frank Heckenbach wrote:
> > > You forgot:
> > >  - NamesConsistingOfMultipleWords (most frequent in my experience)
> > True. But using different concatenations resulting in the same
> > identifier (such as `FooBar' and `FoobAr' -- I know there are real
> > examples of this, I just don't have them in mind right now) is
> 
> There's the case I mentioned above:
> 
> http://www.gnu-pascal.de/crystal/gpc/en/mail7664.html
> [...]
> Got Here is quite different from Go There!

Yes, thanks for digging it out.

> Frank Heckenbach wrote:
> > asking for trouble in a case-insensitive language. In C, you can do
> > this and get away with it. In Pascal, sooner or later, you might use
> > those names in the same scope and get a conflict.
> 
> No.  If they are within the same scope, then there SHOULD be a
> conflict.

So to repeat my argument with this concrete example, here's a (made
up) code fragment which shows the problems I'm referring to. Adding
the `with' statement (because it makes it more comfortable to access
the `Target' field twice) shadows, in the statement between,
`GoThere' by `Field[Position].GotHere'. This is a tricky bug, hard
to find if you don't know it.

Of course, such unintended shadowing can happen with the same
capitalization as well. But in this case, the programmer can notice
it, whereas a programmer who thinks case-sensitively, as you
suggest, will not even understand the problem.

You might argue that a declaration-capitalization-warning will catch
this case. But only if compiled on such a compiler (you mentioned
using other compilers) and if enabled (it's optional as you know).
Whereas the identifier-capitalization-warning can catch it even
before the actual conflict arises, as soon as the two identical
identifiers with different capitalization are introduced, if it's
compiled just *once* with GPC and the warning enabled. So you can
notice it earlier and prevent the actual conflict by renaming things
(there are always choices to rename things).

program Foo;

const
  Max = 20;

type
  t = record
    { Target of link from this position }
    Target: Integer;

    { Position was already visited }
    GotHere: Boolean
  end;

var
  Position: Integer;
  Field: array [1 .. Max] of t;
  PositionsToTry: set of 1 .. Max;

procedure p;
var NewPosition: Integer;

  { Set the current position to NewPosition. Return True if successful. }
  function GoThere: Boolean;
  begin
    if NewPosition in [1 .. Max] then
      begin
        Position := NewPosition;
        GoThere := True
      end
    else
      GoThere := False
  end;

begin

  { Try next position }
  NewPosition := Position + 1;
  if GoThere then Exit;  { OK }

  { Try other positions on the list }
  for NewPosition in PositionsToTry do
    if GoThere then Exit;  { OK }

  { Try target of link from current position }
  with Field[Position] do
    begin
      NewPosition := Target;
      if GoThere then Exit;  { Ouch! }
      Target := 0  { invalidate link }
    end;

end;

begin
end.

> Frank Heckenbach wrote:
> > > And we should divide programmers into two groups, one that does not
> > > care about capitalization and the second that cares. The first group
> > > produces lot of meaningless variation, but they are irrelevant for
> > > the discussion since they wish no warning. The second group IMHO 
> > > is much more likely to associate meaning with capitalization.
> > 
> > So do I, yet I prefer to avoid different capitalizations of the same
> > identifier (see above).
> 
> That's fine, but it does not suit everyone, and you apparently haven't
> run into a condition where there would be a conflict.

I have, and I liked to get the warning. See the example above. Even
if there was no direct conflict such as the one shown above yet, you
are inviting one if you use the same identifier with different
capitalization for different purposes. Pretending to be
case-sensitive is nice, but you have to respect the limits.

> Frank Heckenbach wrote:
> > So is the lack of `endif', and a few other things IMHO. We can't
> > change the fundamentals of Pascal, I'm afraid.
> 
> Agreed!  But this discussion is not about changing the fundamentals of
> Pascal.  It's about changing how GFP reacts to case inconsistency when
> it is requested to check for case consistency.  Programmers will
> expect the case usage to match the scope of the variable.

Since I'm no programmer (according to your definition), I can't help
you here, sorry.

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