FreePascal made it to project of the month on Sourceforge

[edwinyzh]

so it's very clear to see what will happen after the js code returns a value, otherwise I'll have to define the call back in another method. 

The trouble is that that is a matter of personal preferences. I think it also complicates overviewing what a method does in one glance.

Well, if the callback is long than I agree with you that it's better to put the code as a separate method, but when the code is short I prefer to use a mechanism like Python's lambda (but support multiple line code blocks).

[edwinyzh]

Apart from the code cleanliness, another benefit that anonymous methods makes it easy to use local variables, this part I don't go further here, but it's also a great benefit.

Actually that is called a closure isn't it? And you do not need an anonymous method for a closure. You could use a nested named procedure instead, if closures were implemented (and if they were implemented using nested procs)

Well, as a matter of fact, I did mix the concept of a closure and anonymous method. And while actually what I want to most is closure.

As for your suggestion of implementing closure by adding a special modifier to nested functions, as I replied to @marcov above, it look like a better way of using closures, but in case of short callback code blocks, I think anonymous method implementation like Python's lambda (but support multiline of code blocks) is better, because the code logic is clearer (sequential and in one place).
Jut my two cents.

[Robert W.B.]

Thanks Florian and the team for Freepascal and Lazarus.
Best regards
Robbanux

[Leledumbo]

We'll, that'll be too much of a hassle for an average to figure out how to use that FPC branch with the official Lazarus, while being uncertained and worried about it not including the latest bugfixes in the latest trunk.

It's not for average user yet, the reason why it's on separate branch. Average user should use stable, or trunk if required and only other branches if they want to improve it.

I don't believe that by providing anonymous methods will result in executable size increment to a level that overweighs the benefit of anonymous methods.

You never code it in a compiled language, don't you? Go on and try it yourself.

[marcov]

Closure vs anonymous method yes.  Nested proc vs closure/anonymous no. The nested proc passed as closure only has validity as long as the frame of its parent on the stack is intact.  Anonymous methods are afaik implemented as an under the hood interface that allocates dedicated space on the heap for what it captures in, and is freed when no longer need.

But that is a question of what what the compiler implements.

Passing nested functions with access to parent state are supported *now* :-)

Code: [Select]

{$modeswitch nestedprocvars}

 Type TMyCallback=procedure(Index:Integer) is nested;


Except for a "nested" procedure, that should be used as closure, may be named different. So the name "nested" may then be wrong. (and it would technically not be "nested" as it would not have all the properties that a current nested has /but it would be declared in a very similar way)

Yes, simply a not inline declared function is the best term I guess.

With a clean slate I would favor such development, but as usual I think Delphi compatibility should prevail.  That's better then ending up with two such constructs.

[edwinyzh]

I don't believe that by providing anonymous methods will result in executable size increment to a level that overweighs the benefit of anonymous methods.

You never code it in a compiled language, don't you? Go on and try it yourself.

Actually, I use anonymous method in Delphi and I haven't noticed nor I heard that it results in significant exe size increment. On the other hand, Generics and enhanced RTTI in Delphi adds noticeable extra file size to the bin output.

[Leledumbo]

Actually, I use anonymous method in Delphi and I haven't noticed nor I heard that it results in significant exe size increment.

Do you have a lot of anonymous methods with similar body? If not, then it's expected. Otherwise, Delphi compiler has found a good way to optimize that away better than Haskell compiler does (well, actually there's a difference in philosophy as well, where Haskell compiler tends to think "you can buy space, but not time" so they sacrifice size for speed).

[motaz]

        Do you ernestly think that people, who you thaught to be high school students in 1999 are still at high school? 


    No, I meant there were a team, not only one person


So if it is a person then he graduated from high school, if it is a team they are still in high school?

Taaz

High school has no relation to my comments about team work vs one person there, it seems that you can't understand.
anyway it doesn't matter.

[taazz]

I was only kidding. just kidding.

[motaz]

I was only kidding. just kidding.

I thought you still can't understand
sorry

[marcov]

Actually, I use anonymous method in Delphi and I haven't noticed nor I heard that it results in significant exe size increment.

Do you have a lot of anonymous methods with similar body?

Anonymous methods generate some code yes. For each afaik an interface is defined, plus code to move the captured state to the interface. But that is normal overhead, like adding a small class and one or two methods with say an automated type as parameter. Nothing extreme.

The extended RTTI is really a totally different magnitude, and to a lesser degree also generics (afaik though, Delphi doesn't really try to optimize generics(*), so the implementation is actually worse than the design).

(*) Delphi generics contrary to the earlier FPC and C++ ones follows a strict declare before use principle. This makes it much easier to share implementations for cases that only differ in typing. Exploiting this properly is probably a global optimization of which Delphi has few.

[VTwin]

Congratulations! Long live Free Pascal! 

Thanks Florian and the FPC team, your work is greatly appreciated.

Cheers,
Frederick

[nsunny]

This is the sign for Rise of Lazarus/Free Pascal. I get the feeling that Pascal will once again be popular. I hope it gets the spotlight it deserves.

Congrats to Lazarus/FPC team.

[BeniBela]

I get the feeling that Pascal will once again be popular.

To become popular it needs to get much more awards, and that soon:

https://lh6.googleusercontent.com/-mv1puZ-1t5k/U0tu-L4GoYI/AAAAAAAAAJ0/1bbOo9KvmUg/w1202-h752-no/13-18.png

[kapibara]

No one has been promoting ObjectPascal for a decade or more so thats not surprising, but it could soon get somewhat exciting. Who knows what will happen when a fantastic product, that doesn't cost anything, comes into the view of more and more people.

I think Pascal lovers have reasons to be optimistic.