Are forward declarations really necessary?

[Ryan J]

In all of my Pascal projects I end up having a "Base" or "Global" unit which has abstract classes I need to inherit from and some virtual methods which are used to avoid circular references. Many of these can be solved by "uses" in the implementation section and declaring types in the interface section but there's always a few cases where this doesn't work.

It's not just annoying to write but it also has downstream effects where I need to cast to the concrete class in all subsequent files and override virtual methods which has overhead. I'm sure everyone knows what I mean so I won't give any examples.

My questions is, are these are specific limitations or language philosophies that means this can't be solved? I feel like it's in a deficiency of the compiler and it could be resolved using a second pass type resolution system (many languages do this already).

[cdbc]

Hi
I guess, it's the price we pay, for a 'One Pass Compiler'...
Have you tried to work with interfaces, both COM & CORBA, they'll give you more freedom... 
Regards Benny

[TRon]

I feel like it's in a deficiency of the compiler and it could be resolved using a second pass type resolution system (many languages do this already).

There will not be additional passes added to the compiler. This has been discussed multiple times and the standpoint was made clear for each and every discussion. I do not believe that view has changed.

[Thaddy]

My questions is, are these are specific limitations or language philosophies that means this can't be solved? I feel like it's in a deficiency of the compiler and it could be resolved using a second pass type resolution system (many languages do this already).

Pascal aims to be a single pass compiler (well, FPC isn't strictly speaking). That means that the compiler needs some kind of look ahead to be able to resolve constructs (classes, methods, etc) that at some point are not fully defined yet.
Forward declarations exist just because of that.
Multi-pass compilers are dead slow. Single pass compilers much faster, but at a cost. This is one of them.
I have some code written in C++ with an equivalent in FreePascal where C++ takes 3 minutes and FPC takes 3 seconds to compile.
So yes, for a Pascal compiler a mechanism like forward declarations is necessary.
That does not mean you can not write a multi pass Pascal compiler, the old and abandoned GNU pascal comes to mind, but is a philosophy you either love or hate: loose compile speed vs very little gain in optimization.

But  you can make the compile cycle slow and multi pass by using WPO  what is great for release builds. To my mind there is not much conceptual difference between WPO and a C++ optimizing compiler.

But actually you know all that....

(WPO really works a treat on large projects, btw)

[marcov]

My questions is, are these are specific limitations or language philosophies that means this can't be solved? I feel like it's in a deficiency of the compiler and it could be resolved using a second pass type resolution system (many languages do this already).

As with many features there are advantages and disadvantages to both methods, and the ones you stress matter how the choice is made.

The second pass resolution system has to merge different type of information of various passes, and ambiguity can happen.  Quite often the differences are especially with regards to quality error generation in cases when there is something wrong with the structure.

Also you only get most errors if the whole file can be parsed , while now you get most errors directly. A big disadvantage IMHO. When you are rearranging stuff you must first get a global situation roughly parsing before the real errors come.

Anyway it is all academic since this is so fundamental to the compiler it most likely won't ever change. If you change it, it is a different product.

But it would be interesting how Java/.NET-Pascal hybrids like PascalABC.NET and Oxygene deal with this.

[Ryan J]

If compilation speed is badly hurt then I'd rather have my forward declarations but I'm skeptical it's really so slow on modern computers.

I'm trying to envision how this would work and it would basically be crawling all the types looking for undefined types and then resolving them. If there aren't many types in a unit then this isn't so bad. As for the units with lots of types maybe that would be a problem if you were compiling that file often.

I know it won't be added I was curious what other people thought about this because I always feel a little badly when I have to make these forward declaration units when the compiler could doing this for me.

[PascalDragon]

Pascal aims to be a single pass compiler (well, FPC isn't strictly speaking).

If one only considers the parser then FPC is a single pass compiler (or parser to be more specific).

My questions is, are these are specific limitations or language philosophies that means this can't be solved?

The language philosophy is “declare before use” and is one of the main principles of Pascal along with “separation of declaration and definition” and we uphold these, because they lead to clearer code.

(many languages do this already).

Pascal is not “many languages”. It doesn't follow hypes.

[Ryan J]

Hi
I guess, it's the price we pay, for a 'One Pass Compiler'...
Have you tried to work with interfaces, both COM & CORBA, they'll give you more freedom... 
Regards Benny

Yes you can get fancy in some cases but this is adding more complexity and interfaces have overhead of their own. The problem can be solved by putting all the types in one unit also but that is slow to compile also and we're doing it because the compiler can't resolve types from different units. I love Pascals units but they are crippled by this limitation.

[Ryan J]

I feel like it's in a deficiency of the compiler and it could be resolved using a second pass type resolution system (many languages do this already).

There will not be additional passes added to the compiler. This has been discussed multiple times and the standpoint was made clear for each and every discussion. I do not believe that view has changed.

Do you have any links to old discussions? I'm curious about the topic because it seems like a legit shortcoming of Pascal which maybe it's time to reconsider given modern hardware. Maybe a single pass compiler was the obvious choice in 1980 but I'm not so sure if this is true in 2024.

[Ryan J]

The language philosophy is “declare before use” and is one of the main principles of Pascal along with “separation of declaration and definition” and we uphold these, because they lead to clearer code.

To be clear I'm just talking about resolving types from different units which have circular dependancies, not allowing declaring types in any order. The problem can be fixed but moving all types into a single unit but this cripples what's nice about units.

I'm imagining this second pass could be added to the interface section only (so there's no node tree to traverse) and if an undefined type is found then mark it as undefined and when it's found in another unit come back to a list of types which has unresolved references and resolve them. If it was limited to just the interface section it could be feasible I think.

[TRon]

Do you have any links to old discussions?

Not from the top of my head. Though a simple search delivered this (hardly a discussion but a stand/viewpoint).

The bugtracker as well as the mailinglist have seen this topic being discussed as well as these forums.

I'm curious about the topic because it seems like a legit shortcoming of Pascal which maybe it's time to reconsider given modern hardware. Maybe a single pass compiler was the obvious choice in 1980 but I'm not so sure if this is true in 2024.

You seem to forget (perhaps ignore ?  ) that Free pascal also runs on (exotic and/or older) restricted hardware (the raspberry pi which is recent and can be fairly restricted in its hardware capabilities is a good example of that) but also msx, msdos, etc. You could perhaps argue to use cross-compilation instead but that takes away a lot of (native development) comfort.

Other than that you have (somewhat of) a point but I personally also prefer the very fast single pass compilation times. E.g. I can live with the current limitations (though I prefer current bugs to get eradicated but that is a whole other topic in itself)

[PascalDragon]

The language philosophy is “declare before use” and is one of the main principles of Pascal along with “separation of declaration and definition” and we uphold these, because they lead to clearer code.

To be clear I'm just talking about resolving types from different units which have circular dependancies, not allowing declaring types in any order. The problem can be fixed but moving all types into a single unit but this cripples what's nice about units.

For Objective Pascal Jonas had added the concept of formal declarations (TSomeType = objcclass external;) and back then I tried to apply this to Object Pascal classes as well, but there where issues that made this functionality impossible.

So if there should be something, then it would have to follow the concept of the formal declarations like forward declarations, but what will NEVER be is that you can use the type without any kind of declaration (and obviously some situations will not work, like for example inheriting, because for that the full, non-formal type needs to be available, this will also not change).

[Ryan J]

The language philosophy is “declare before use” and is one of the main principles of Pascal along with “separation of declaration and definition” and we uphold these, because they lead to clearer code.

To be clear I'm just talking about resolving types from different units which have circular dependancies, not allowing declaring types in any order. The problem can be fixed but moving all types into a single unit but this cripples what's nice about units.

For Objective Pascal Jonas had added the concept of formal declarations (TSomeType = objcclass external;) and back then I tried to apply this to Object Pascal classes as well, but there where issues that made this functionality impossible.

So if there should be something, then it would have to follow the concept of the formal declarations like forward declarations, but what will NEVER be is that you can use the type without any kind of declaration (and obviously some situations will not work, like for example inheriting, because for that the full, non-formal type needs to be available, this will also not change).

Oh yes I used Objective Pascal extensively and released a number of commercial apps with it (made the parser as you know I'm sure). I took the formal declarations for granted but what did they really do? Just tell the compiler to expect a resolution from another unit?

To be clear I'm talking about this scenario where you have two classes that reference each other but because units are nice and this isn't C we want to put them in their own units. Currently we can do this and have to make abstract classes which are unneeded if the compiler could figure this out.

I guess if you had a formal declaration it would be resolved when the another unit used both these units. It doesn't sound like a breaking change to the language or something intractable to solve.

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

1. unit UnitA;
2. interface
3.  
4. type
5.   TMyClass = class
6.     function GetSomething: TData;
7.   end;
8.  
9. implementation
10.  
11. end.
12.  
13.  
14. unit UnitB;
15. interface
16.  
17. type
18.   TData = class
19.     value: Pointer;
20.     function GetOwner: TMyClass;
21.   end;
22.  
23. implementation
24.  
25. end.

[Curt Carpenter]

...
The language philosophy is “declare before use” and is one of the main principles of Pascal along with “separation of declaration and definition” and we uphold these, because they lead to clearer code.
...

+1

[marcov]

Objective * afaik has more a dispatch object model, and inheritance is not the only way to synthesise objects? That put less of a stress on order of declaration, but that doesn't pass onto Pascal classes, which are wholly declarative.