NewPascal plans, Generics.Collections and FPC trunk

[Mr.Madguy]

I fully understand this and this is for sure subject of my work. The idea of non existing yet "NewPascal" dialect is strong support for meta programming in very clean "Pascal" way with full assistance of existing dialects and well known RTL. The tools like YACC or boost:spirit library should be replaceable by NewPascal dialect in long term future.

I just hate, when code becomes overcomplicated due to compiler limitations. For example multiple inheritance problem. Standard situation:

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

1. type
2.   TAbstactClass1 = class
3.   ...
4.   end;
5.  
6.   TImplementation1 = class(TAbstractClass1)
7.   ...
8.   end;
9.  
10. //But then
11.  
12.   TAbstractClass2 = class(TAbstractClass1)
13.   end;
14.  
15. //Bad thing - I can't reuse TImplementation1 code here.
16. //I have to copy-paste everything. This increases sizes of both sources and code itself,
17. //overcomplicates and increases chance of errors.
18.  
19.   TImplementation2 = class(TAbstractClass2)
20.   end;
21.  
22. //And possible solution is very ugly, slow and memory inefficient
23. //But I have to deal with it
24.  

And I also need some meta-programming features to automate some code. I even have idea of MetaPascal™©® compiler, where compiler itself would be built fully via meta-programming tech, i.e. adding new features wouldn't require compiler modification - it would work like adding new units to your project. That's my dream.

[hnb]

I just hate, when code becomes overcomplicated due to compiler limitations. For example multiple inheritance problem. Standard situation:

This is controversy topic. But some kind of multiple inheritance should be possible with some extensions for "default field". But this is field of research, and for sure eventually "multiple inheritance" will be solved in other way than in C++. This is very dangerous play and is very easy to hurt language.

And I also need some meta-programming features to automate some code. I even have idea of MetaPascal™©® compiler, where compiler itself would be built fully via meta-programming tech, i.e. adding new features wouldn't require compiler modification - it would work like adding new units to your project. That's my dream.

This is my dream too . Anyway the fast revolution is not possible. Rather evolution with start with new NewPascal dialect (which will initially get what is the best from delphi mode and objfpc + some new more oxygene like features).

[tverweij]

I don't think a fork is a good think - it depletes the resources on both.
But I also don't think that an opensource project should ban contributors, because that has the same effect.

About the commits in minor areas: this is a problem I see in all open source projects; the developers do what they want because they are volunteers, so nobody can tell them what to do. But I see the same in payed projects (b.e Microsoft); the developers have to do what the management wants.
In both cases the work that the users want isn't done; as stated in earlier posts: if you want something done, you have to do it yourself. But not every programmer has the skills to do that, making them dependent on the ones that can - hoping that anyone will fix their problems / add the syntax sugar or functionality they need.

An opensource project works on donations. But why donate when the things you want aren't done? Why donate if you have no saying at all in the priorities?
Therefore some suggestions:
1. Don't ban code contributors
2. Make a request list where anyone can add their wishes (needed fixes, needed syntax sugar, needed functionality)
3. Give donators votes to vote on this request list (the more you donate, the more votes you get)
4. Pay a fee (from the donations) to the developers to do the work on the most requested items

Just my 2 cents.

[Handoko]

I agree with most of the things you said.

For your information, Lazarus/FPC has a wishlist page:
http://wiki.freepascal.org/Feature_Ideas

Unfortunately not much users know that page exists.

[guest58172]

This is my dream too . Anyway the fast revolution is not possible. Rather evolution with start with new NewPascal dialect (which will initially get what is the best from delphi mode and objfpc + some new more oxygene like features).

I experienced the joy of metaprog in D and rich of this experience i can say that it's clear that's it's not possible in FPC. This requires multi-pass semantic, templates, and the most important, compile-time reflection. Object Pascal RTTI is an old but well working feature (used for the LCL GUI serialization for example ) but it's not at all adapted to metaprog.
Too much changes to the compiler and language. Maybe a kind of pre-processor could work, to some extent.

[Mr.Madguy]

This is controversy topic. But some kind of multiple inheritance should be possible with some extensions for "default field". But this is field of research, and for sure eventually "multiple inheritance" will be solved in other way than in C++. This is very dangerous play and is very easy to hurt language.

Limited version of multiple inheritance is possible now - via interfaces. And interfaces are actually implemented the same way, as multiple inheritance in C++ - via wrappers, that add some delta to Self reference. So, performance wouldn't be hurt, if we would switch from interfaces to multiple inheritance. And... Using interfaces feels like a crutch programming. They have several drawbacks - no fields, mandatory reference counting, explicit casting via using GUID, etc. And, dunno about FPC, haven't tested it yet, but in Delphi I can't even implement base interface and it's descendants in the same class - I have to use aggregated interfaces and this is as bad, as just using "driver" model.

This doesn't work for me:

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

1. type
2.   IBaseInterface = interface
3.   ...
4.     procedure DoSomething;
5.   end;
6.   IBaseInterfaceAlias1 = interface(IBaseInterface);
7.   IBaseInterfaceAlias2 = interface(IBaseInterface);
8.  
9.   TImplementation = class(TInterfacedObject, IBaseInterface, IBaseInterfaceAlias1, IBaseInterfaceAlias2)
10.     procedure BaseDoSomething;
11.     procedure Alias1DoSomething;
12.     procedure Alias2DoSomething;
13.     procedure IBaseInterface.DoSomething = BaseDoSomething;
14.     procedure IBaseInterfaceAlias1.DoSomething = Alias1DoSomething;
15.     procedure IBaseInterfaceAlias2.DoSomething = Alias2DoSomething;
16.   end;
17.  

There is another possible method. I dunno, what is right name for it - I call it "driver method". It's similar to aggregated interfaces.

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

1. type
2.   TAbstractClass1 = class
3.   ...
4.     procedure DoSomething;virtual;abstract;
5.   ...
6.   end;
7.  
8.   TImplementation1 = class(TAbstractClass1)
9.   ...
10.     procedure DoSomething;override;
11.   ...
12.   end;
13.  
14.   TAbstractClass2 = class(TAbstractClass1)
15.   ...
16.   end;
17.  
18.   TImplementation2 = class(TAbstractClass2)
19.   ...
20.      FClass1Implementation:TAbstractClass1;
21.   ...
22.      constructor Create;
23.      procedure DoSomething;override;
24.   end;  
25.  
26. //Create TAbstractClass1 "driver"
27.  
28. constructor TImplementation2.Create;
29. begin
30.   inherited Create;
31.   FClass1Implementation := TImplementation1.Create;
32. end;
33.  
34. //Wrapper procedure - of course it means source size, code size and performance penalty
35.  
36. procedure TImplementation2.DoSomething;
37. begin
38.   FClass1Implementation.DoSomething;
39. end;
40.  

And multiple inheritance is just more clear and safe way of doing exactly the same things.

I experienced the joy of metaprog in D and rich of this experience i can say that it's clear that's it's not possible in FPC. This requires multi-pass semantic, templates, and the most important, compile-time reflection. Object Pascal RTTI is an old but well working feature (used for the LCL GUI serialization for example ) but it's not at all adapted to metaprog.
Too much changes to the compiler and language. Maybe a kind of pre-processor could work, to some extent.

Meta programming doesn't have to be dynamic. I see meta programs as compiler plugins. Something like Lazarus packages. You write "uses MyMetaModule;" this meta-module have some special structure. First compiler compiles it into some sort of MyMetaModule.dll plugin file (static linking to compiler itself - isn't good idea in this case) and then loads it and compiles program itself using it's features. Something like that.

[hnb]

I don't think a fork is a good think - it depletes the resources on both.
But I also don't think that an opensource project should ban contributors, because that has the same effect.

...

An opensource project works on donations. But why donate when the things you want aren't done? Why donate if you have no saying at all in the priorities?
Therefore some suggestions:
1. Don't ban code contributors
2. Make a request list where anyone can add their wishes (needed fixes, needed syntax sugar, needed functionality)
3. Give donators votes to vote on this request list (the more you donate, the more votes you get)
4. Pay a fee (from the donations) to the developers to do the work on the most requested items

I fully agree almost with all. I agree that the fork is not good thing, but in my situation for the moment I have no choice (all was explained above...). Ok maybe the alternative is stopping all my work for compiler and RTL... Incoming weeks will be hard for me: many work not much visible in public (see below). After CI systems, more community things can be done (request list, voting, etc).

@BBasile, @Handoko, @Mr.Madguy : before I will continue my work on new compiler stuff a lot of work must be done, here I mean fully automated CI systems, especially:

* better auto-testing for compiler and mORMot (with easy to use page for looking for problems)
* auto releases for more platforms than just for Windows  (maybe with few cross-compilers "out of box")

no fireworks yet

[Zoran]

So, while we're talking about a new and modern Pascal, can you provide named parameter feature? I think it's good and fit with Pascal's philosophy.

Does it? It fits in Python philosophy...

@bee every idea is welcome in NewPascal, I was not thinking about this feature yet, but looks promising and is worth to investigate! This may be a little delayed because I have a lot of work with reactivation of NewPascal. But when I finish I will back to this for sure.

I found that someone asked for it here: http://wiki.freepascal.org/Feature_Ideas#.22default.22-value_in_a_proc_or_function_call
I'm posting this because of the interesting comment below it:

If such a feature should exist, wouldn't it be more straightforward to simply not specify anything before the comma? (i.e. "Fly(, Amelia);")

Personally, I'm not a big fan of this feature at all, but I should say that the way proposed by this comment appeals much more to me than writing parameter names in function calls.
So, when (if ever) you start working on this, please think about the latter way.

[Thaddy]

So, while we're talking about a new and modern Pascal, can you provide named parameter feature? I think it's good and fit with Pascal's philosophy.

Does it? It fits in Python philosophy...

It is actual Visual Basic philosophy. Not a good idea for register allocation and parsing. Can be done. I'd rather not see it in Pascal.

Personally, I'm not a big fan of this feature at all, but I should say that the way proposed by this comment appeals much more to me than writing parameter names in function calls.
So, when (if ever) you start working on this, please think about the latter way.

Where's the "feature" in that proposed "feature"?

[bee]

Does it? It fits in Python philosophy...

Many programming languages share some same principles, concepts, and philosophy. There's no such a programming language that truly unique in its whole concepts and principles. Some reasons why I love Pascal are the clarity, readability, and discipline. Though sometimes I feel it too verbose, but in the end I realize that it's Pascal, that's the way it is. If I need a different concepts and principles, I should use other programming language that fits my need better.

However, no matter how good Pascal's concepts and principles are, the implementation should be dynamic along the time. That's how a technology grows and evolves so it becomes better. In fact, many concepts that previously considered unpascalish, then somehow slowly accepted and implemented in Pascal using the Pascal's way. Otherwise, today we would be still using Wirth's Pascal implementation in the 70's.

Named parameter is adding clarity and readability to method parameters. I wonder why Pascal doesn't implement it since the beginning. However, as a new feature, I know it shouldn't break existing codes, so I proposed it as an option via {$modeswitch namedparameter} (or through a command line parameter, -Sp perhaps?). If you need it, simply enable it. If you don't, it won't bother you whatsoever.

If such a feature should exist, wouldn't it be more straightforward to simply not specify anything before the comma? (i.e. "Fly(, Amelia);")

No, it's very not pascalish. Comma is a punctuation. It completes something else. So, it should not exist all alone by itself. If you don't want to specify something then don't specify at all.

Personally, I'm not a big fan of this feature at all, but I should say that the way proposed by this comment appeals much more to me than writing parameter names in function calls.

Then it's not for you. But I think it's good that it's available as an option. I'll use it for sure.

[Mr.Madguy]

I found that someone asked for it here: http://wiki.freepascal.org/Feature_Ideas#.22default.22-value_in_a_proc_or_function_call

Yeah, I would also want this feature. And I don't really understand, why there is such limitation - only last procedure/function parameters can have default values? It's purely meta-programming feature. I.e. if any parameter is skipped - it should be replaced with default value. As simple, as that. I.e. something like this should work:

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

1. procedure TList.Slice(AStart:Integer=0;AEnd:Integer=-1;AStep:Integer=1);
2. begin
3. ...
4. end;
5.  
6. MyList.Slice(2,,2);
7.  

And I also don't see, why such declaration is impossible:

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

1. procedure SomeProc(A:Integer=0;B, C:Integer);
2.  

It's purely matter of Pascal standard - there is no such thing, as parameter skipping or default parameter symbol (something like "_" symbol) there. And this is purely parsing problem, I guess.

[howardpc]

And I also don't see, why such declaration is impossible

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

1. procedure SomeProc(A:Integer=0;B, C:Integer);
2.  

It's purely matter of Pascal standard - there is no such thing, as parameter skipping or default parameter symbol (something like "_" symbol) there. And this is purely parsing problem, I guess.

I imagine it is not a parsing problem. Obviously it could be done. It is a question of adopting syntax that slows down the compiler parser (which I believe is single-pass) as little as possible. If you require default parameters to be located it a certain position, you can parse slightly more quickly than if you have to plod through each element separately, to check if it is given a default or not. I prefer Object Pascal's compilation speed over C++'s multiple options and coffee-break length compilation. I honestly think it helps to be more productive when you can code/compile/unit-test in a second or two, rather than minutes or even longer intervals.

[Mr.Madguy]

Previously I had been giving you examples only, but I've analysed situation and, yeah, I have a list of features, I personally want to see in Pascal. Funny thing - I've never programmed on C/C++ seriously, but all my problems with Pascal boil down to lack of certain C/C++ features:
1) Delphi 2009 support, i.e. generics, closures and full Unicode support.
2) Multiple inheritance. Yeah, I can emulate it in Pascal, but my code suffers from memory usage and performance penalties, cuz code isn't optimized at binary level. Yeah, for example I use exactly the same wrappers, but they obviously aren't just ADD EAX, X and JMP Y. And of course it causes unclear and low quality code.
3) Extended operator overloading support. Overriding default := handling, similar to C/C++ "operator =" for example. Shorter explanation - I need to automate some assignment and initialization/finalization code for classes in a similar way, interfaces are handled, but without actually using interfaces.

[Chronos]

Previously I had been giving you examples only, but I've analysed situation and, yeah, I have a list of features, I personally want to see in Pascal. Funny thing - I've never programmed on C/C++ seriously, but all my problems with Pascal boil down to lack of certain C/C++ features:
1) Delphi 2009 support, i.e. generics, closures and full Unicode support.
2) Multiple inheritance. Yeah, I can emulate it in Pascal, but my code suffers from memory usage and performance penalties, cuz code isn't optimized at binary level. Yeah, for example I use exactly the same wrappers, but they obviously aren't just ADD EAX, X and JMP Y. And of course it causes unclear and low quality code.
3) Extended operator overloading support. Overriding default := handling, similar to C/C++ "operator =" for example. Shorter explanation - I need to automate some assignment and initialization/finalization code for classes in a similar way, interfaces are handled, but without actually using interfaces.

1) Support for Delphi "new" features is always welcomed. I would personally like to have kind of FreeDelphi rather then FreePascal.
2) Multiple inheritance is problematic and usually not worth the cost. Therefore many language designers decided to not allow it.
3) This style operators overloading is already supported by FPC. http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Operator_Overloading_%28Delphi%29

[Mr.Madguy]

1) Support for Delphi "new" features is always welcomed. I would personally like to have kind of FreeDelphi rather then FreePascal.
2) Multiple inheritance is problematic and usually not worth the cost. Therefore many language designers decided to not allow it.
3) This style operators overloading is already supported by FPC. http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Operator_Overloading_%28Delphi%29

2) Sorry, but this is the reason, why some people think, that C++ is better, than Pascal, and that at some point, when you become professional enough - you should migrate to C++. I've analysed it many times - there are no other way to complete my task in Pascal, other than so called class composition - i.e. storing references to ancestor classes right inside descendant classes and declaring 3-4 levels of wrapper methods. Otherwise I wouldn't be able to reuse code and that would mean copy-pasting exactly the same code many times, wasting memory on lots of references and extreme code size inflation. This is extremely clunky solution and means large memory usage and performance penalties. And while multiple inheritance implementation isn't free and uses similar methods, it's optimized at binary level, as in this case compiler knows, what should be done - for example wrappers have minimal possible code. And code becomes much more clear, readable and consistent. I've just tested my ideas in Borland C++ 3.1 - even this archaic compiler do this job perfectly.
3) Assignment operator isn't supported, as I know. You can't declare "operator Implicit(A:TMyType):TMyType" - compiler would complain about it.