Nested declarations inside advanced record

[440bx]

I find this kind of passive-aggressive condescension very irritating.

I can understand that.  For the record, the individuals that get that from me more than earned it. 

Maybe you should take a look in the mirror before calling everyone who disagrees with you a stubborn know-it-all.

I take a look in the mirror every day.  It's not a matter of agreeing or disagreeing, it's a matter of simple decency and  honesty.  Warfley was given _multiple_ opportunities to explain his position but, since he is wrong and lacking both the honesty and the knowledge to acknowledge that, he gets and will keep getting the attitude from me that you find irritating.

What really irritates me are dishonesty, ignorance and continuous refusal to acknowledge being wrong when their being wrong is totally obvious.  I have little patience for that. period.  Being patient in the face of that kind of behavior just promotes more of it, not something that should be promoted.

All that said, for the record, I don't enjoy it but, I have no problem dishing out what someone worked hard to earn.

[Warfley]

What really irritates me are dishonesty, ignorance and continuous refusal to acknowledge being wrong when their being wrong is totally obvious.

You mean like, for example, if someone uses a well established term you haven't heard before, and the first reflex is to claim it's not used by anyone in the field, without doing even the slightest bit of checking which would have found that this term is used everywhere?

[440bx]

You mean like, for example, if someone uses a well established term you haven't heard before, and the first reflex is to claim it's not used by anyone in the field, without doing even the slightest bit of checking

First, I acknowledged the existence of the term, unlike you who has not acknowledged that the "duplicate identifier" message from the compiler stems from the fact that the parameter(s) and local variable(s) are in the same scope,
Second, as far as not doing "the slightest bit of checking", that is a malicious claim.  I have lost count of the number of compiler construction books I've read, not to mention compiler source code and I have not seen the term "shadowing" the way you used it.  That said, I openly conceded in the other thread and concede that the way you used it is correct.

which would have found that this term is used everywhere?

I have serious doubts about that because other than it being used by GCC (pointed out by PascalDragon), I haven't seen it used anywhere else but, I might have missed it being used here and there by other compilers, that's possible.

On the other hand, if it is used "everywhere" as you claim, show where FPC uses it. Everywhere should include FPC.  Just in case, used in a place that is visible to any user such as an error, warning or hint message.  You claim it's used everywhere, here is your chance to demonstrate your claim isn't simply more b.s. from you.

OTH,  let's have a look at your code again:

Code: Pascal  [Select][+][-]

1.  procedure foo(x: Integer);
2. var
3.   x: Double;
4. begin
5. end;

Since you _dishonestly_ claim that the parameter "x" and the local variable "x" are not in the same scope, explain why a Pascal compiler emits a "duplicate identifier" error message.  As I stated a good number of times before: you got some explaining to do.

Now what ? are you going to post another pile of garbage about FPC source code that's neither here nor there ?  It's simple: explain why the compiler emits a "duplicate identifier" message, the reason is totally independent of how a compiler chooses to implement scope resolution.

I stand by every word I typed about you in my reply to @Khrys and your previous post only provides an additional example.

[Warfley]

First, I acknowledged the existence of the term, unlike you who has not acknowledged that the "duplicate identifier" message from the compiler stems from the fact that the parameter(s) and local variable(s) are in the same scope,
Second, as far as not doing "the slightest bit of checking", that is a malicious claim.  I have lost count of the number of compiler construction books I've read, not to mention compiler source code and I have not seen the term "shadowing" the way you used it.  That said, I openly conceded in the other thread and concede that the way you used it is correct.

Yeah you did concede, but only after denying that this term is widely used twice. That's the point, instead of going: "I don't know that term, I should search it up" you went straight to "I don't know that term therefore he must be wrong in using it"

I have serious doubts about that because other than it being used by GCC (pointed out by PascalDragon), I haven't seen it used anywhere else but, I might have missed it being used here and there by other compilers, that's possible.

Just timed: I just hit up Google with the query "shadowing site:clang.llvm.org" and found results in the clang documentation within less than a minute. I can do the same for "shadowing site:openjdk.org" or "shadowing site:python.org" just to check the tree most popular compilers/interpreters and I find results.

Again, it's not that you didn't know the term, and yeah you did concede, but the fact that you claimed first that this term isn't real and second that no big Compiler uses the term with such confidence, that's the problem I have with you.

[440bx]

Maybe you have a reading comprehension problem (in addition to others)... I asked for the term used in error, warning or hint messages.  I concede that the term exists and it is used, That said, I still have serious doubts it is as common as you imply it is because I don't see it used in compiler books, compiler source code and compiler messages.  It does appear in "Engineering a compiler" but not used the way you imply.   

Since you claimed the term is used "everywhere", I'd like to see where it's used in FPC.  Did you not comprehend the request ?  or did you skip that for convenience because your use of "everywhere" is not quite "accurate" (being nice here.)

Also, you apparently "forgot" to answer the question about your code:

Code: Pascal  [Select][+][-]

1.  procedure foo(x: Integer);
2. var
3.   x: Double;
4. begin
5. end;

If the parameter and the local variable are not in the same scope, why does the compiler emit a "duplicate identifier" ?  You've been asked quite a bit more than twice and the correct (and honest) answer is  still yet to come.  I have little doubt that instead of answering the question you'll come back with something about "shadowing" being used "everywhere". 

Because of that, I take your non-answer reply as yet another example that my statements to Khris about you are fully accurate and fully deserved.

I'd be very surprised if your next post was not another pile of neither here nor there babble in yet another effort to sidestep the correct (and honest) answer.  but, surprise me.

[Warfley]

Maybe you have a reading comprehension problem (in addition to others)... I asked for the term used in error, warning or hint messages.  I concede that the term exists and it is used, That said, I still have serious doubts it is as common as you imply it is because I don't see it used in compiler books, compiler source code and compiler messages.  It does appear in "Engineering a compiler" but not used the way you imply.

As I said, I've worked on multiple compilers and the term is beeing used everywhere. Like the internal clang documentation, the openjdk documentation or the python documentation.

Again it's a term that if you work on any active Compiler development, you will come across. Even when the word is not used in the Compiler sources themselves, you will see it used in issues or merge requests. While it is a term used by the official python documentation to describe certain behavior, you'll find most occurrences of the term in the python enhancement proposals, i.e. where individual authors or third parties bring in their proposals to the language.

Even if a Compiler itself is not using the term, if you work with compilers and interact with those communities, you will come across that term. So even if the authors of the python spec do not use it themselves, in order to write the spec they interact with proposals that use that term.

Again I have worked on actively developed compilers and programming languages, I also follow the development in some open source systems quite closely.
Maybe it's not that widely used in the academic literature (even though I learned the definition in my language engineering course at uni), but if you actually work in the field you will come across it

Also, you apparently "forgot" to answer the question about your code:

I have answered that question 4 times. Just to be very slowly for you again: The "Duplicate Identifier" message does not mean that two identifiers are in the same scope, it is thrown in multiple different circumstances, even in ones where the two symbols are clearly not in the same scope (as I have demonstrated). You're argument that because the "Duplicate Identifier" message is thrown, they are in the same scope, is just fallacious.

I did not "forgot" about it, I just did not want to drag that discussion to this thread also... There is nothing more to the discussion. I mean I rest asured that Niklaus Wirth in his book on Compiler Construction in section 12.4 has parameters and local declarations in different scopes (and yeah while it is for oberon, the visibility rules for variables and parameters in oberon are identical to pascal)... So if you only trust books (which again you shouldn't actual live compilers are much more authoratative on how compilers work than theoretical books), whose more trustworthy according to you Brinch Hansen or Niklaus Wirth?

[dsiders]

@Warfley, @440BX

Do you guys have to commandeer every thread for your little pissing contest?

[440bx]

You're argument that because the "Duplicate Identifier" message is thrown, they are in the same scope, is just fallacious.

Really ?  explain why the compiler is emitting that message.   You're really good at claiming nonsense but, you still have some explaining to do.  I'll hint you the obvious: two identifiers cannot be duplicates of each other if they are in different scopes.

Here is the question _again_ (read slooooowly): if the parameters and the local variables are in different scopes explain why the compiler emits a duplicate identifier message.  What's the reason the compiler emits that message ? It's a simple question.

whose more trustworthy according to you Brinch Hansen or Niklaus Wirth?

Are you suggesting that Per Brinch Hansen got scoping wrong  ????.    Guess what.. what N. Wirth says in his book is the _same_ as what Per Brinch Hansen says in his.  The problem is: you don't understand what you read.  Now, I'd like you to explain how is it possible that PBH's compilers work if, as you claim, he doesn't get scoping right.  That should be interesting.

You really should read Per Brinch Hansen On Pascal Compilers.  IMO, it's the easiest/simplest introduction on compiler construction.  You should pay particular attention to the section about scopes I mentioned in a previous post.  After you read that book (multiple times would be good), follow that with Pemberton's comments on the P5 source code and you'll have a reasonably good foundation.

After you do that, you'll be able to answer the simple question you bend over backwards to avoid answering.

@Warfley, @440BX

Do you guys have to commandeer every thread for your little pissing contest?

No, AFAIC, only this one.  Note that I did not reply to his post in the other thread.

[dbannon]

@Warfley, @440BX

Do you guys have to commandeer every thread for your little pissing contest?

Well said Don. Honestly, the OP's question was answered in the first few posts, lets bring this to a close. Guys, you are obviously not going to convince the other one, so please stop trying !

Davo

[440bx]

Guys, you are obviously not going to convince the other one, so please stop trying !

It's not a matter of convincing anyone.  My problem is that what he is stating is wrong and it is therefore misleading and mis-informing the forum users.    That's why I won't let go. 

The reason the compiler emits a "duplicate identifier" error message is because the parameters and the local variables are in the same scope.  His pretending that is not the case is dishonest and misleading.  It is completely unacceptable.

[Warfley]

I'll hint you the obvious: two identifiers cannot be duplicates of each other if they are in different scopes.

So just to understand you correctly, you say that if two identifiers are in different scopes, fpc would *never* throw a duplicate identifier message? If yes, you are simply wrong. If no, your argument doesnt make any sense.

Again I don't want to go into that further because your argument does not make any sense. I've demonstrated that the exact same error message is thrown for identifiers of different scopes (where you yourself said that the identifiers are in different scopes). So saying that because of that error message they must be in the same scope does not make any sense

Well said Don. Honestly, the OP's question was answered in the first few posts, lets bring this to a close. Guys, you are obviously not going to convince the other one, so please stop trying !

I tried to stop, and didn't answer in the last thread, but he brought it up again in this thread...

[440bx]

Warfley, you just can't stop posting that garbage of yours, totally unable to do the right thing.  Again, explain why the compiler emits a "duplicate identifier" error message.  If those two identifiers are not in the same scope then explain why the compiler emits that message ? 

And stop referring to FPC, it has nothing to do with FPC.  _ANY_ Pascal compiler would emit a duplicate identifier on that code.

Also, stop being so disgustingly dishonest.  This isn't about what I say, it's about language design.  See the reference to Per Brinch Hansen in the post: https://forum.lazarus.freepascal.org/index.php/topic,69755.msg542815.html#msg542815

Of course, he must be wrong because what he shows there is what you don't have the decency and honesty to admit, it's literally _drawn_ there for you.  Stop misleading readers,  answer the question (which is answered in PBH's book for you) or concede you are wrong.  Period.  You'll survive being honest, the majority of people "survive" it every day.

[jamie]

@440 why do u have to be so cantankerous, go restock your supply of MIDOL.

[440bx]

@440 why do u have to be so cantankerous, go restock your supply of MIDOL.

I'm so sorry that expecting honesty from someone gets in your way too but, I have to say, it's no surprise it does.

[Warfley]

And stop referring to FPC, it has nothing to do with FPC.  _ANY_ Pascal compiler would emit a duplicate identifier on that code.

So logically speaking you say, For All Pascal Compilers follows that they will throw that error? So the falsification of that is: There exists at least one Pascal Compiler that doesn't throw that message?

So I just made a fork of the FPC: https://gitlab.com/Warfley/fpcsource/-/tree/argument?ref_type=heads
It allows the following:

Code: Pascal  [Select][+][-]

1. procedure foo(x: integer);
2. var x: Integer;
3. begin
4.  
5. end;

But not this:

Code: Pascal  [Select][+][-]

1. procedure foo;
2. var x: Integer;
3.   x: Double; // Duplicate identifier
4. begin
5.  
6. end;

It is certainly exists and it is a pascal compiler, because it compiles any pascal program that FPC also compiles. I even tested it compiling both itself, the FCL and Lazarus all working flawlessly.
So now there exists at least one Pascal compiler that does not throw a duplicate identifier error there.


Note this change is just changing a single false to a true:

Code: Pascal  [Select][+][-]

1.         { check also parasymtable, this needs to be done here because
2.           of the special situation with the funcret sym that needs to be
3.           hidden for tp and delphi modes }
4.         hsym:=tsym(tabstractprocdef(defowner).parast.FindWithHash(hashedid));
5.         if assigned(hsym) then
6.           begin
7.             { a local and the function can have the same
8.               name in TP and Delphi, but RESULT not }
9.             if (m_duplicate_names in current_settings.modeswitches) and
10.                (sym.typ in [absolutevarsym,localvarsym]) and
11.                (vo_is_funcret in tabstractvarsym(sym).varoptions) and
12.                not((m_result in current_settings.modeswitches) and
13.                    (vo_is_result in tabstractvarsym(sym).varoptions)) then
14.               Hidesym(sym)
15.             else
16.               DuplicateSym(hashedid,sym,hsym,true); // <-- this true was a false before
17.             result:=true;
18.             exit;
19.           end;  

in symtable.pas. The reason this is so simple is because params and local variables are in different scopes, and there is just this one special case which does a cross scope check. If they would be in the same scope, it would be much more difficult to change that, as then I would have to deal with name collisions and stuff like that. But because they are in different scopes, I just need to change this single line and change the behavior from throwing an error to just shadowing the parameter.