Nobody should take my word for it, instead read the chapter on scopes in Per Brinch Hansen's book which you can find at:
http://pascal.hansotten.com/uploads/pbh/brinch%20hansen%20on%20pascal%20compilers%20OCR.pdf
The chapter starts at page 95 (book page number) or page 105 (online pdf reader page number)
Specifically, read section "6.3 COMPILATION METHOD" and pay particular attention to Figure 1's first column which clearly shows that parameters, local variables, types and constants are all in the same scope _within_ a procedure or function. These are pages 110 & 111 (online pdf reader page numbers.)
You actually for the first time in this thread provided some evidence on your own... I'm proud of you. I mean you still did not provide a definition for scope, infact the section you've referenced specifically talks about how you can implement scoping by a stack of symbols...
But wait a minute, haven't you argued that I shouldn't bring up a specific implementation, now you do the exact same. You literally just do the same thing you said was wrong when I did it. You bring up a specific way of implementing a compiler as proof on how scopes should work.
With the small difference that I brought up the implementation in the FPC the compiler for the language this discussion is about, while you bring up the work of a guy who built a pascal compiler 40 years ago that no one is using anymore.
Do you really think that the way Brinch Hansen implemented a pascal compiler nearly half a decade ago is more of an authority on modern day pascal than than the way modern pascal compilers are implemented today?
But because I am a pedant, let's look further in that book, because there is the section "Scoping Rules" which contains a sentence thats most closely to a definition for a scope:
To make this idea precise we need a set of rules that enable a programmer (and a compiler!) to associate every occurrence of a name with a definition of the corresponding object.
So a scope is some concept that allows for the resolution of names according to a certain set of rules. This is actually the same definition that clang uses, so it's not just some weird thing in a book from the 80s, but something that is acutally used by real world compilers.
So if two objects resolve names differently, they are in different scopes. There are two ways to interpret this, either pedantically, so as soon as there is any discrepency between name resolution of two objects they are in a different scope, e.g.:
procedure foo(x: Integer);
var
y: Integer = sizeof(x);
begin end;
This works fine, but the following doesn't:
procedure foo(x: Integer = SizeOf(y));
var
y: Integer;
begin end;
So x and y clearly have different rules for resolving the name, because y can reference x but x can't reference y. While this would be from a formal point of view probably be the best interpretation, as this allows for formal verification over properties. This hase the side effect that any identifier introduces a new scope:
var
x: Integer;
y: Integer = sizeof(x);
z: Integer = sizeof(y);
From a strictly formal perspective x creates a new scope for all following definitions such that x can be used. Same for y and z. So if my goal is to write a formal definition of the Pascal semantic, this would be the way to go.
Now I know why you didn't go with that definition, because this while being very formal, is not very useful in practice when building a compiler (because here you can enforce the scoping rules through the order of parsing the code top to bottom). That said it's great that your own source says that you are wrong :)
And lastly, because you bring that very bad argument up again and again not realizing how it makes you look stupid:
For the record, in the following code: procedure foo(x: Integer);
var
x: Double;
begin
end;
the parameter "x" and local variable "x" are in the same scope which is the reason any Pascal compiler, including FPC, will declare there is a duplicate identifier. This is rather simple stuff, no rocket science here.
[...]
Now, let's give the obvious answer: the reason FPC emits a "duplicate identifier" error message is because the parameter and the local variable are in the same scope. It's that simple. Period.
Again this argument is just fallacious. Your argument is formalized:
1. If two objects in the same scope have the same name, they will cause a duplicate identifier error
2. the parameter and variable in this example cause a duplicate identifier error
3. Therefore these two objects are in the same scope.
But 3 does not follow from 1 and 2, because this is just an implication not an equivalence. If two objects are in the same scope they get a duplicate identifier. But this does not mean that if you get duplicate identifier they are in the same scope. To prove that this argument is fallacious a simple proof by contradiction is enough, in that I just need to find a single example where I get the same error but the two variables are not in the same scope:
type
TTest = object
i: Integer;
procedure foo(i: Integer);
end;
Here the parameter i and the object field i are not in the same scope, the parameter is in the scope of the function definition and the field is in the scope of the object. Still there is a duplicate identifier. Therefore you're argumentation is wrong. Just flat out provably wrong.
Yeah and you are right, it's not rocket science, it's a logical fallacy you are proposing here. I know implication vs equivalence is something many first semester students struggle with, so I don't feel to bad about missing this part