I couldn't care less how FPC implements its scope resolution mechanism but that comment proves that you know less about compiler construction than the Pope knows about quantum mechanics. Locals and parameters are in the same scope which is why locals cannot have the same name as parameters because that would cause a duplicate identifier.
I have worked with multiple compilers, amongst others clang, which I hope you agree is a mainstream compiler. I have never seen the parameter list not being in their own scope, even though it may not be semantically accessible in the language.
For example, while the following does not work right now in fpc:
procedure foo(i: Integer);
var j: Integer = i;
begin
end;
Because i and j are in different scopes, there is no semantic reason for it not to work. It's mainly that the way the FPC variable initialization is currently implemented it can only read constants directly written into the assembly.
But other languages allow exactly that.
Even FPC will tell you there is a duplicate identifier thereby conclusively proving the parameter and the local are in the same scope.
Do you know where FPC also complains with the exact same error message?
{$mode objfpc}{$H+}
{$ModeSwitch advancedrecords}
type
TTest = record
i: Integer;
procedure Foo(i: Integer);
end;
And I hope we both agree that these two i's are not in the same scope right?
As I suggested in the previous post, you need to read a few books about compiler construction.
I've taken multiple courses in Uni about compiler construction, read multiple books and papers about compiler construction, I've build my own Regex and LALR table generator, I've worked on the source code of multiple compilers including clang.
I regularly create small scripting languages to be used within my programs.
I'm by no means an expert on all areas of compiler construction, infact I rarely work on the backend side but usually do frontend work (i.e. lexing, parsing and AST construction/modification), but I certainly know more than enough about these topics for this discussion here.
Again you didn't know that shadowing is a commonly used term. About mainstream compilers, all common C compilers, gcc, clang, MSVC++ use the term. The Glasgow Haskell Compiler uses the term, the Python Documentation and linters use the term, the OpenJDK Documentation usese the term. Like I do not know how you can use any currently popular programming language and never encounter this term
Honestly I feel that your knowledge on the topic is just severly out of date, because I do not know a single language system (at least one conceived in the past 25 years) which does not use the term.
You tell me to read books, but be honest, have you read anything that came out in the past 10 years on the topic? Knowedge is not something you acquire once, especially in a field like computer science, which is a very young science, it's constantly evolving, to be knowlegable on a topic requires to keep up with the modern developments.
A language like Rust and the Rust compiler could not have existed 20 years ago, because the relevant research in Constraint Satisfaction Theories has just been discovered during the past 15 years. I know that, because I was a student of one of the Professors who did some of the most important discoveries in that area, at that time
Also over the past 10-20 thanks to the widespread access to well versioned and documented open source software, we are now finally able to have meta analysis on language features and how they impact programming behavior, alowing to analyze scientifically what patterns and development paradigms produce more or less bugs, are better maintainable, etc.
Those are things that 20 years ago were simply not possible. If you do not refresh your knowledge but only rely on the books on compiler theory from Wirth or Hoare from the 60s and 70s, while they are a very excellent introduction to the topic, they are just that, the very basics. Today the field is so much bigger, with so much more stuff to know and learn about...
I don't doubt that you once were a great programmer, but from how and what you write, not just here, it feels like your knowledge is stuck in the 80s and 90s, and you still rely on that knowledge alone, ignoring the past 20-30 years of development in the field