Therefore, should I assume that nested declarations of types and constants are also possible with advanced records?In theory it should because objects and classes are just extensions of advanced records.
Thanks in advance.
In theory it should because objects and classes are just extensions of advanced records.Well, that is not true, although it might be conceptually true.
Advanced records are the "seed" of OOP. That's where it all starts. Conceptually, Classes/Objects = Advanced records + inheritance + polymorphism.
Well, that is not true, although it might be conceptually true.There is no "might" about it.
There is no "might" about it.Except that the language that introduced OOP was SmallTalk, which didn't have records. Infact SmallTalk is not a classical procedural language to begin with (SmallTalk is Expression based not Statement based).
Except that the language that introduced OOP was SmallTalk
Historically this is not true: the first language that introduced OOP was SimulaRight my mistake, SmallTalk was the first OOP language (i.e. including all the concepts like meta classes and stuff like that) , but the first language to introduce objects and the basic OOP concepts was Simula you are right.
(https://en.wikipedia.org/wiki/Object-oriented_programming)
So sorryYou are rather sorry... you got that right.
Apparently you're another one of those that thinks that what happens in FPC is how the world turns.Well, that is the order in which they were introduced in delphi/freepascal and TurboPascal does not even have advanced records, like it or not.
Try to figure this out.. what critical characteristic of OOP do advanced records showcase ?Arghhhh, encapsulation, isn't it?
Yes, encapsulation.Try to figure this out.. what critical characteristic of OOP do advanced records showcase ?Arghhhh, encapsulation, isn't it?
Stop nagging, Thaddy is right about that - most of us have experienced that transition while programming since the TP era.
Since the inception of Pascal.and then came the Big Bang because there was nothing before Pascal.
All records can be nested, advanced or not. Simple answer and correct.
Since the inception of Pascal.
Try to figure this out.. what critical characteristic of OOP do advanced records showcase ?
reply when AND IF you figure out the answer. Ask ChatGPT, it might be able to find the answer for you (and Thaddy.)
Therefore, should I assume that nested declarations of types and constants are also possible with advanced records?In theory it should because objects and classes are just extensions of advanced records.
Thanks in advance.
Advanced records are the "seed" of OOP. That's where it all starts. Conceptually, Classes/Objects = Advanced records + inheritance + polymorphism.
<snip> as well as methods declared in them.THAT is the seed of OOP. That's encapsulation and without it there is no OOP.
THAT is the seed of OOP. That's encapsulation and without it there is no OOP.
It looks like some people think that if it didn't start in the Pascal language then it must not exist.
<snip> as well as methods declared in them.THAT is the seed of OOP. That's encapsulation and without it there is no OOP.
It looks like some people think that if it didn't start in the Pascal language then it must not exist.
It isn't about records... it is about the pairing of data and procedures in a dedicated structure which is what advanced records are and bring to the table. That pairing is the door to OOP, without that, there is no OOP.
The name that pairing is given is irrelevant. It's the concept's existence that matters, regardless of name. Once you have that, you can extend the concept with inheritance and polymorphism. Without encapsulation, you cannot have those and without those there is no OOP.
Saying any one of them is the "seed" of OOP is not quite trueI am not correcting you for your benefit but for others who may be reading this.
So sorryYou are rather sorry... you got that right.
[...]
reply when AND IF you figure out the answer. Ask ChatGPT, it might be able to find the answer for you (and Thaddy.)
There is one thing that has been clearly re-enforced by a select few forums participants and that is that, some people are surprisingly resistant to acquiring knowledge. I guess it might have something to do with the fact that most of them seem to believe they know everything and were born that way (or got their "infinite" knowledge from reading FPC source code <chuckle>.)
The conclusion is: the results, which are usually very poor, are not worth my time.
[...]
Thaddy is _always_ right... haven't you figured that out yet ? ... and he is not the only one.
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.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?
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 checkingFirst, 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,
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.
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,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"
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.
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.
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.
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.
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.
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.
@Warfley, @440BXNo, AFAIC, only this one. Note that I did not reply to his post in the other thread.
Do you guys have to commandeer every thread for your little pissing contest?
@Warfley, @440BX
Do you guys have to commandeer every thread for your little pissing contest?
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.
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.
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...
@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.
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?
Ok, so here's my theory to hopefully settle this once and for all:This is truly unbelievable.
Parameters and local variables are in different (albeit nested) scopes, and FPC explicitly disallows shadowing the former through a special check in symtable.pas (see Warfley's post).
This means that the "duplicate identifier" error message is a misnomer in this case; being an exception to the usual rules (shadowing generally being allowed), it should be marked as such.
Parameters and local variables are in the same scope [...]
You know the answer to that: because Y is defined _after_ procedure Bar. As I have no doubt you know, Pascal requires all identifiers to be defined before they can be accessed.Parameters and local variables are in the same scope [...]
Why can Bar access Foo's parameter X but not its local variable Y then?
That said, you still haven't explained why Pascal compilers (that don't include code from you... LOL) emit a "duplicate identifier" error message. The reason is genuinely trivial.Interesting, so do you say that the FPC is a pascal compiler only if it doesn't contain code by me? If so, I'm sorry to tell you but the FPC already contains code by me since 2023 :)
Interesting, so do you say that the FPC is a pascal compiler only if it doesn't contain code by me? If so, I'm sorry to tell you but the FPC already contains code by me since 2023 :)No, what I am saying is that a Pascal compiler is significantly more likely to function correctly (and sensibly) if it doesn't contain code from you.
However FPC implements its scope resolution is as irrelevant to scope resolution as the color of the Pope's underwear on Tuesdays.
Does anyone really think that Delphi, Gnu Pascal, UCSD Pascal, etc, etc, use the same algorithms and code as FPC ? really ???? Stop inhaling red paint for breakfast, it's not good for you.
The symbol table consists of lists of elements, one for each scope (see Section 8.2). TheHere the definition of a scope is completely practical, a scope is just an entry in the stack of symbol lists that form the symbol table.
elements consist of the name (identifier) and a reference to the identified object.
Again your problem is you lack a consistent definition of what a scope is. What is a definition that encompasses what you are talking about?No, that is your problem. I _showed_ you what a scope is and encompasses by referring to PBH's chapter on scoping where he even draws the scopes and what they contain.
Here is your code slightly modified [...]
We must also specify in which part of a block an object can be referenced. This part of the block is called the scope of the object. An object is said to be known in its scope.
Local variable Y can not be referenced inside Bar.That is so ridiculous, it's unbelievable.
In your example "Y" couldn't be referenced because it had not been defined. It's not a matter of scopes, it's a matter of definition sequence. Unbelievable!!!
In the implementation of the FPC compiler, symbol tables for local variables and symbol tables for parameters were separated only for check duplication on the names of properties and method parameters in the class.No parameters are in a different symtable for many more reasons, most importantly to match forward declarations. When the compiler finds a local implementation of a procedure, it checks if it has already found a forward declaration that contains the same symbols, as in ObjFPC not just the signature must be identical but the symbols must be identical:
Back to an earlier topic on the thread.. I’m curious why advanced records were needed when classes and objects already existed?No. Simply because inheritance and polymorphism aren't always needed and, when they aren't, simple (un-extended) encapsulation is more efficient.
Was it because Delphi was doing it or ?
It may be scope on the same level, but it is not the same scope.What the "level"?
What the "level"?This is something I have also brought up in the discussion multiple times, especially in my last post. On a theoretical level specifically for program analysis, every identifier spans their own scope. This is how you model scopes in analysis and formalizing the code. It's a valid definition that's used in practice.
From FPC doc Scope (https://www.freepascal.org/docs-html/current/ref/refse116.html#x237-26100016.6): Identifiers are valid from the point of their declaration until the end of the block in which the declaration occurred. The range where the identifier is known is the scope of the identifier.
The parameters are declared inside the function and are valid until its end.
It's so simple and obvious, and it's also well-known. It seems to me that @Warfley and @Thaddy are just trolling out of boredom.
There is no definition of scope where parameters and local variables have the same scopeThe only thing greater than your incompetence is your dishonesty. PBH _draws_ the scopes in his book clearly showing the parameters and the local variables residing in the same scope.
A new scope is opened at the top of the stack whenever the parser encounters a procedure, and it is closed when the parser has finished with this procedure.Of course, you'll babble some garbage to argue the meaning of that. Never mind that the guy worked with N. Wirth (obviously you know better than him too, that should go without saying) One scope per procedure clearly implies the procedure's parameters and its locals are in the same scope (not to mention other declarations that can reside in a procedure.)
PBH _draws_ the scopes in his book clearly showing the parameters and the local variables residing in the same scope.He draws the scopes how it is convinient for the reference implementation he builds throughout the book implements them, but where is his that compiler and how many people are it today? FPC draws scopes how it is convinient for it's implementation, you know for a compiler that finds real world usage.
In both cases the scopes are based on whats convinient for the implementation.and that is a lie. The implementation is usually driven by convenience BUT, the concept is NOT a matter of convenience.
Scope is nothing more than an isolation level. ASerge at al. refuse to get that.
I believe that is from forum user @Fibonacci. I believe it was AI generated.Scope is nothing more than an isolation level. ASerge at al. refuse to get that.
Nice avatar Thaddy, the cat from the lamp =)
I believe that is from forum user @Fibonacci. I believe it was AI generated.Scope is nothing more than an isolation level. ASerge at al. refuse to get that.
Nice avatar Thaddy, the cat from the lamp =)
and that is a lie. The implementation is usually driven by convenience BUT, the concept is NOT a matter of convenience.You are getting there :) Like the concept of the scope of a variable is the block where it is visible, so as was shown multiple times already, a variable can only be referenced after it has been declared, therefore it's scope starts below it's definition. Thats literally the concept described in the book:
We must also specify in which part of a block an object can be refer-So the scope of an object starts at it's definition and ends at the end of the block the definition occurs in. This is the concept that PBH describes. But then for the implementation purposes PBH creates a symtable stack of lists, which he visualizes. So the drawing you referring to is already a deviation from the concept PBH has introduced just 4 pages earlier.
enced, This part of the block is called the scope of the object. An object is said to be known in its scope.
Roughly speaking, an object defined in a block is known from its definition to the end of the block.
As the drawing in PBH's book clearly shows, the parameters and the local variables are in the same scope. A drawing is NOT an implementation and, in this case, that is rather inconvenient for you. <chuckle>That is just an abstraction thats convinient for the reference compiler he built in his book. As it deviates from his own definition of a scope above.
You are referencing a single didactic decision PBH made to visualize a very simple compiler, oversimplified infact, to make the introduction into compilers easy.Whether a compiler is simple or not, the concepts don't change. In Pascal, parameters are in the same scope as local variables. Apparently this simple concept is too complex for you to comprehend. Your attempt to devalue PBH's work clearly reflects the kind of person you are.
A new scope is opened at the top of the stack whenever the parser encounters a procedure, and it is closed when the parser has finished with this procedure.Maybe N. Wirth and Hanspeter Mössenböck didn't work on compilers that are complex enough for you. That must be the reason... no doubt.
I don't know which one is right... :oI assure you, Per Brinch Hansen is right as are N. Wirth and Hanspeter Mössenböck. This should not be a surprise to anyone.
An object is said to be known in its scope. Roughly speaking, an object defined in a block is known from its definition to the end of the block.So he clearly writes black and white an objects scope is from its definition to the end of the block. This means any definition creates its own scope, and therefore no two objects have the same scope.
Brinch Hansen says:PBH didn't draw a separate scope for every variable and parameter in the section about scoping. Go look at the drawing again.QuoteAn object is said to be known in its scope. Roughly speaking, an object defined in a block is known from its definition to the end of the block.So he clearly writes black and white an objects scope is from its definition to the end of the block. This means any definition creates its own scope, and therefore no two objects have the same scope.
An unfortunate example, because y defined AFTER x. The same asY can reference x but not the other way around, because they have different scopes
PBH didn't draw a separate scope for every variable and parameter in the section about scoping. Go look at the drawing again.Yes the drawings are illustrations of the technical abstractions of this concept he used to implement his compiler. Any technical abstraction will somewhat diverge from the theoretical concept. This is what I'm telling you for the past probably 15 posts now.
An unfortunate example, because y defined AFTER x. The same asThe example shows exactly what I am describing. On a theoretical level, no two (separate) declarations can have the same scope.
5 Symbol Table HandlingIn case you "no comprende" yet, that means, one scope per procedure block.
A symbol table maps the names in a program to their attributes such as their types and their addresses. It consists of several subtables (scopes), one for every module, procedure and record type. As a consequence of single pass compilation, which Wirth preferred in his later compilers, the scopes can be organized in a stack-like way. A new scope is opened at the top of the stack whenever the parser encounters a procedure, and it is closed when the parser has finished with this procedure.
The scope of parameters and local variables starts at the beginning of the procedure block and ends at the end of the procedure block. Where their visibility starts is not the same.Now you are just plainly contradicting your own source:
We must also specify in which part of a block an object can be referenced, This part of the block is called the scope of the object.Brinch Hansen defines the part of a block where a object can be referenced (i.e. it's visibility) as the scope of the object.
Nice try but definitely not. The visibility of an identifier is not the same as the scope in which it is defined. The scope starts where the procedure block starts, the identifier's visibility starts once it is fully defined. The scope contains the identifier definitions.QuoteWe must also specify in which part of a block an object can be referenced, This part of the block is called the scope of the object.Brinch Hansen defines the part of a block where a object can be referenced (i.e. it's visibility) as the scope of the object.
And what about this valid program, I don't understand what's going on here:
But with his recent activity If I had to choose between two evals I think I'll upgrade.Let them know you disapprove of how they implement the "with" statement, no doubt they'll "correct" that for you...
Edit: now I understand y = y is not possible. Done! The same if it was v = v in that scope...You got it.
read some books!You brought up a book and are now contradicting what is written black on white without any room for interpretation in the very same book you brought up.
Still at it I see. All it takes is one to destroy it for everyone else, be it this thread or other threads currently boiling.Speaking of which I recently came across this thread in the mailing lists. https://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg57220.html
I've be kicking my heals lately if I should upgrade from D 11 to 12, not sure if the coast is worth it since that too seems to have some minor issues.
But with his recent activity If I had to choose between two evals I think I'll upgrade.
If there are individuals campaigning here to discourage the use of fpc/Lazarus, it's working.
Jamie
I think I don't need book advice from you :)You need a lot more than advice. As I said, educate yourself, hopefully after you gain some basic knowledge you'll stop spreading your ignorance. Start with PBH's On Pascal Compilers, you really need to get a grasp of the basics.
I’ll never forget the time long ago when a thread discussion which was quite pleasant and had many participants was suddenly locked upon the whim of a moderator who decided it was off topic. At least that thread was a positive experience that didn’t make the community look bad. I can’t say the same for many threads I’ve seen since...
I’ll never get over my disappointment about the lively discussion that was locked and lost opportunity to make friends and learn new things that will never happen again because apparently this type of thread is the best we can do now. We have become spectators of a fight rather than accomplishing something useful for making people want to use fpc.
@pascaldragon
It’s possible to move a conversation that has gone off topic to a new thread instead of ruining it. I’ve seen it done before so I know it can be done.