Re: [fpc-devel] Delphi anonymous methods

2013-03-07 Thread Alexander Shishkin

03.03.2013 2:22, Sven Barth пишет:

On 02.03.2013 20:55, Sven Barth wrote:

Also there are open questions which require brainstorm:
1. Does Pascal needs other implementation of closures which is different
from anonymous methods implementation?


I would say no. After all the method implementation itself stays the
same, but the captured variables should be different. Or what does this
print:


I've now read through your PDF and somehow I'd like to have a better
implementation in FPC. Let's consider the following code (Note: I've
never used anonymous methods yet, so this is what I naively would expect):

=== code begin ===

var
   i: LongInt;
   SomeProc1, SomeProc2: reference to procedure;
begin
   i := 42;

   SomeProc1 := procedure
begin
  Writeln('Proc1: ' + i);
end;

   i := 21;

   SomeProc2 := procedure
begin
  Writeln('Proc2: ' + i);
end;

   SomeProc1;
   SomeProc2;
end;

=== code end ===

The output I'd expect here is the following:

=== output begin ===

42
21

=== output end ===

But if I've understood you correctly I'll get the following instead:

=== output begin ===

21
21



BTW closurs in c++ support both cases (capture by value and by reference).



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-06 Thread Roberto P.
{$MODE MINE} would suit as well :-)


2013/3/6 Thaddy 

> {$MODE SUBJECTIVE} is more appropriate in this discussion.
>
> But i am by -first - education a political scientist.
>
>
> On 6-3-2013 15:44, Michael Schnell wrote:
>
>> On 03/06/2013 02:37 PM, Sven Barth wrote:
>>
>>> What exactly do you mean?
>>>
>>
>> we already have:
>> {$MODE FPC}
>> {$MODE OBTP}
>> {$MODE DELPHI}
>> {$MODE OBJFPC}
>> {$MODE OBJMAC}
>>
>> if {$MODE OBJMAC} not already is for objective Pascal there could be
>> something like
>>
>> {$MODE OBJECTIVE}
>>
>> -Michael
>> __**_
>> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
>> http://lists.freepascal.org/**mailman/listinfo/fpc-devel
>>
>
>
> __**_
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/**mailman/listinfo/fpc-devel
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-06 Thread Thaddy

{$MODE SUBJECTIVE} is more appropriate in this discussion.

But i am by -first - education a political scientist.

On 6-3-2013 15:44, Michael Schnell wrote:

On 03/06/2013 02:37 PM, Sven Barth wrote:

What exactly do you mean?


we already have:
{$MODE FPC}
{$MODE OBTP}
{$MODE DELPHI}
{$MODE OBJFPC}
{$MODE OBJMAC}

if {$MODE OBJMAC} not already is for objective Pascal there could be 
something like


{$MODE OBJECTIVE}

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-06 Thread Sven Barth

Am 06.03.2013 15:19, schrieb Graeme Geldenhuys:

On 2013-03-05 13:02, Sven Barth wrote:

Two words: backwards compatibility.

To Turbo Pascal yes (ie: tp mode), but surely not ObjFPC?
You must not forget that mode ObjFPC isn't the youngest one either. If 
we'd freshly design that mode I'd agree with you, but we now have many 
users that use that mode and might rely on the point that $J+ is set. 
Only because you don't use it doesn't mean that noone does.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-06 Thread Michael Schnell

On 03/06/2013 02:37 PM, Sven Barth wrote:

What exactly do you mean?


we already have:
{$MODE FPC}
{$MODE OBTP}
{$MODE DELPHI}
{$MODE OBJFPC}
{$MODE OBJMAC}

if {$MODE OBJMAC} not already is for objective Pascal there could be 
something like


{$MODE OBJECTIVE}

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-06 Thread Graeme Geldenhuys
On 2013-03-05 13:02, Sven Barth wrote:
>>
> Two words: backwards compatibility.

To Turbo Pascal yes (ie: tp mode), but surely not ObjFPC?


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-06 Thread Sven Barth

Am 06.03.2013 14:35, schrieb Michael Schnell:

On 03/06/2013 01:45 PM, Sven Barth wrote:
There is a mode that's compatible to Mac Pascal, but the Objective 
Pascal is independant of the mode, but is triggered by a modeswitch 
(as it was specially developed by the FPC and the Mac Pascal 
communities).


Would it not be nice and more straightforward to have a {$ definition 
for same, too ?

What exactly do you mean?

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-06 Thread Michael Schnell

On 03/06/2013 01:45 PM, Sven Barth wrote:
There is a mode that's compatible to Mac Pascal, but the Objective 
Pascal is independant of the mode, but is triggered by a modeswitch 
(as it was specially developed by the FPC and the Mac Pascal 
communities).


Would it not be nice and more straightforward to have a {$ definition 
for same, too ?


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-06 Thread Sven Barth

Am 06.03.2013 11:57, schrieb Michael Schnell:

On 03/05/2013 08:52 PM, Graeme Geldenhuys wrote:
Good thing is, most of these are kept in the 'delphi' compiler mode. 
The 'objfpc' mode normally get some more pascal love.

+1

AFAIK there is an Apple specific Objective Pascal mode, as well. I 
think it's really nice to have multiple compilers in one (some 
tolerable cost  regarding compiler speed not withstanding).
There is a mode that's compatible to Mac Pascal, but the Objective 
Pascal is independant of the mode, but is triggered by a modeswitch (as 
it was specially developed by the FPC and the Mac Pascal communities).


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-06 Thread Michael Schnell

On 03/06/2013 01:54 AM, Frank Church wrote:

I have observed a lot of Delphi developers who have written code that
needs or depends on the features like anonymous methods, generics,
RTTI

or Strings :-[

give up porting to FPC because it proved too difficult, but then
it turns out those libraries could greatly enhance FPC usage.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-06 Thread Michael Schnell

On 03/05/2013 08:52 PM, Graeme Geldenhuys wrote:
Good thing is, most of these are kept in the 'delphi' compiler mode. 
The 'objfpc' mode normally get some more pascal love.

+1

AFAIK there is an Apple specific Objective Pascal mode, as well. I think 
it's really nice to have multiple compilers in one (some tolerable cost  
regarding compiler speed not withstanding).


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-06 Thread Michael Fuchs

Am 05.03.2013 14:02, schrieb Sven Barth:

You can disable this construct with:
http://www.freepascal.org/docs-html/prog/progsu42.html


This should be the default in ObjFpc mode.


Two words: backwards compatibility.


For every version of fpc exists an user changes list, containing items 
which breaks backwards compatibility.


Michael

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Frank Church
I have observed a lot of Delphi developers who have written code that
needs or depends on the features like anonymous methods, generics,
RTTI give up porting to FPC because it proved too difficult, but then
it turns out those libraries could greatly enhance FPC usage.

So I think this bullet must be bitten once to enable those libraries
to be ported over, by FPC achieving parity or syntax compatibility in
that area. Once that is done the FPC development team should make it
clear where they don't agree with Embarcadero's approach, so
developers who want to port to FPC don't depend on any funny stuff
Embarcadero might concoct in the future.

It may even turn out that in the future Delphi will be the one that
has to follow FPCs lead or accommodate it, if this issue is
successfully resolved, just as Microsoft has had to accommodate Linux.

The more developers can accomplish with FPC and Linux the less
relevant the restrictive and proprietary Windows and Mac environments
become and that is what FPC devs should keep in sight.

-- 
Frank Church

===
http://devblog.brahmancreations.com
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Boian Mitov
I equally love and hate the tools (spare Scheme and Java) :-D . So hence the 
smiling faces.


I needed the performance boos and speed of development they are giving me. 
The development before that was way too slow :-( .
I have increased the productivity multiple times by doing that. I also did 
more insane things to do that, like writing my own Design time API on top of 
the Delphi one. This virtually eliminated the need to develop design time 
editors, as I do it with just adding few attributes now.
Second, I am financing the development of our own proprietary development 
language, and in few years may port everything to it.
I also have the option to pay some developers to add the necessary features 
to FPC if it comes to that :-D .

So I am not short on options :-P .
I am insane, but not "that" insane :-D .

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Henry Vermaak

Sent: Tuesday, March 05, 2013 2:20 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods


You sure have a lot of smiley faces for a person so full of hate :)

In all seriousness, what were you thinking when you used all the latest
features of a language that's closed source?  I can understand that it
makes your code better (arguably, perhaps), but you've locked yourself
into the Delphi world now, and it's unlikely that freepascal will ever
satisfy you if you chase after the latest features, since it will take
too long to implement and stabilise.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Henry Vermaak
On Tue, Mar 05, 2013 at 09:56:21AM -0800, Boian Mitov wrote:
> Hi Henry,
> 
> Interesting that you consider me a Delphi fanboy :-D .
> I don't like it much, but I surely love the anonymous methods :-D .
> I love the C++11 implementation of anonymous methods more however,
> but I hate the lack of extensive RTTI in C++ (and FPC).
> I am hard to please, and no fan of any specific language. I hate
> them, and love them equally with only one exception, well maybe 2. I
> highly dislike Java, and I hate Scheme! :-D .
> And BTW: I hate my products too, so that is why I keep working to
> improve them all the time :-D, they are never good enough for me! I
> am equal opportunity hater!

You sure have a lot of smiley faces for a person so full of hate :)

In all seriousness, what were you thinking when you used all the latest
features of a language that's closed source?  I can understand that it
makes your code better (arguably, perhaps), but you've locked yourself
into the Delphi world now, and it's unlikely that freepascal will ever
satisfy you if you chase after the latest features, since it will take
too long to implement and stabilise.

Henry
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Graeme Geldenhuys
On 2013-03-05 15:24, Marcos Douglas wrote:
> 
> Why follow the Delphi even knowing that is the wrong way to implement 
> something?

Because like the FPC team have said a million times to me because
they follow Delphi blindly, and WILL do everything to stay "delphi
compatible".

Good thing is, most of these are kept in the 'delphi' compiler mode. The
'objfpc' mode normally get some more pascal love.


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Boian Mitov
Hmm... you are running on the assumptions that humans are parsers. I for one 
do analyze the logic not the sequence, maybe because I usually write code 
for parallel execution. Humans do not think and follow code as computers, 
and often code that is easy to parse is difficult to follow by human IMHO. 
Otherwise we all would have been writing in Assembler ;-) .


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Alexander Klenin

Sent: Tuesday, March 05, 2013 3:30 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

It is hard to parse for humans as well as for the compiler.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Boian Mitov

Hi Henry,

Interesting that you consider me a Delphi fanboy :-D .
I don't like it much, but I surely love the anonymous methods :-D .
I love the C++11 implementation of anonymous methods more however, but I 
hate the lack of extensive RTTI in C++ (and FPC).
I am hard to please, and no fan of any specific language. I hate them, and 
love them equally with only one exception, well maybe 2. I highly dislike 
Java, and I hate Scheme! :-D .
And BTW: I hate my products too, so that is why I keep working to improve 
them all the time :-D, they are never good enough for me! I am equal 
opportunity hater!


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Henry Vermaak

Sent: Tuesday, March 05, 2013 2:05 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

And with the attitude of, e.g. Boian, we see that it's simply too hard
to please hard-core delphi fanboys.  They're all "take" and no "give".
I look forward to the day when the fpc developers will realise that
playing eternal catch-up is never going to work.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Boian Mitov

Agree :-) .
A native Linux version is planned. It will be however done with either 
Lazarus or Delphi if its Linux version becomes available next year, or our 
own non Pascal compiler in the next couple of years if that one gets ready.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Michael Van Canneyt

Sent: Monday, March 04, 2013 11:51 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

A pity.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread waldo kitty

On 3/5/2013 04:20, Graeme Geldenhuys wrote:

On 2013-03-04 20:33, Howard Page-Clark wrote:


You can simulate this in FPC as well as TP by using a local typed
constant. e.g.

function GetValue: integer;
const value: integer = 0;
begin
Inc(value);
Result:= value;
end;



I've seen this before, and always been baffled by this. How can you
increment a "constant"? If you can, it is then a variable, no?


yep... i also call all named storage items variables even if they are 
constants... what else do you call them in a generic sense? ;)


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread waldo kitty

On 3/4/2013 15:33, Howard Page-Clark wrote:

On 04/03/13 6:34, waldo kitty wrote:


i'm trying to understand what you mean by

> Pascal don't allows to create static variables inside function
> like in c-like languages.

i've done something that i think is what you speak of but it was in
Borland's Turbo Pascal... at least TP6... i don't remember how we did it
though and can't find any sample code in my library :(


You can simulate this in FPC as well as TP by using a local typed constant. e.g.

function GetValue: integer;
const value: integer = 0;
begin
Inc(value);
Result:= value;
end;

Successive calls to GetValue() will return 1, 2, 3 etc.


yes, that is exactly what i was thinking of... i just could not find any sample 
code in my library... as noted, i have used it and it sounds similar to what the 
OP is looking to do... one thing i used to use it for was counting the number of 
time that a routine was called during the course of execution... other times i 
used it were in relation to recursion IIRC...


NOTE: i've never done this with strings but i would guess it would work, too...
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Marcos Douglas
On Tue, Mar 5, 2013 at 11:46 AM, Paul Ishenin  wrote:
> 05.03.13, 21:00, Marcos Douglas пишет:
>
>> So now we have 7!  ;-)
>> I want to keep the language sane too.
>
>
> I wrote not about sane/insane. Delphi adds features to pascal the way they
> want - this is reality. We can't do anything with this. If they add a
> feature not the sane way we can't undo their feature. From that moment
> language become so - with this feature. Whether we want or no. Sooner or
> later we will have to deal with this feature exactly as Delphi developers
> see it.

But if something isn't good enough, why spend time to codify this?

> What I was against is to add the second implementation for already existent
> language feature.

Why follow the Delphi even knowing that is the wrong way to implement something?

> But after mail of Michael I already look at this more tolerant now. So
> please let's stop this endless dispute about nothing. We have different
> vision and this is good after all.

Ok.

Best regards,
Marcos Douglas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Florian Klaempfl

Am 05.03.2013 11:10, schrieb Paul Ishenin:

05.03.13, 17:55, Sven Barth wrote:


@Paul: see? :)


I see you, Graeme, Michael and probably some more 5-6 developers.


Even if those are the only ones, from the beginning, FPC tried to 
support all niches. And if someone maintaines a certain niche, the niche 
will be continued to be support. Actually, I think FPC lives from niches 
and developers working on niches.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Paul Ishenin

05.03.13, 21:00, Marcos Douglas пишет:

So now we have 7!  ;-)
I want to keep the language sane too.


I wrote not about sane/insane. Delphi adds features to pascal the way 
they want - this is reality. We can't do anything with this. If they add 
a feature not the sane way we can't undo their feature. From that moment 
language become so - with this feature. Whether we want or no. Sooner or 
later we will have to deal with this feature exactly as Delphi 
developers see it.


What I was against is to add the second implementation for already 
existent language feature.


But after mail of Michael I already look at this more tolerant now. So 
please let's stop this endless dispute about nothing. We have different 
vision and this is good after all.


Best regards,
Paul Ishenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Vasiliy Kevroletin

On 03/05/2013 05:34 AM, waldo kitty wrote:
It is as I thought about closures before. But this is useless without 
capturing
of variables by value. During creation of anonymous method you *can 
not bind any
values* to it. Anonymous method have only references to captured 
variables.
Pascal don't allows to create static variables inside function like 
in c-like
languages. So you also not able to create unique static variable 
which available
only to one instance of same anonymous method. Even if implementation 
will
create many separate objects for one anonymous function then all 
instances will

be equivalent. Because all instances will refer to same data.


i'm trying to understand what you mean by

> Pascal don't allows to create static variables inside function like 
in c-like

> languages.

i've done something that i think is what you speak of but it was in 
Borland's Turbo Pascal... at least TP6... i don't remember how we did 
it though and can't find any sample code in my library :(


what happened is that the value did not get cleared between 
invocations of the routine and subsequent executions could use the 
value already stored... this breaks, of course, if the memory area for 
the routine is cleared first...


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Word "static" is mistake here, sorry. It should be "local" variable instead.
As it was said in this thread: closure is a way to create object (no 
mean named closure or anonymous). Closure is a routine with all 
variables which it accesses (or "captures" in terminology of Delphi or 
C++). So closure is routine + captured data. I expected that Delphi will 
create one object for one closure.
In example below I was expecting to see creation of 10 different 
objects. But Delphi creates only 1 object. I was surprised.


=== example
for i := 1 to 10 begin
arr[i] := procedure begin
 ...
 end;
===
All arr[i] have same value(same reference).

Actually Delphi creates object(called FrameObject in Delphi's docs) for 
closure otherwise it will not work. But Delphi creates this object not 
for every closure but only for procedure where closure defined. This 
details described in pdf file which I attached in first message of 
thread. Also Sven created good comments which describes how Delphi 
implements closures and how capturing by value should work 
http://lists.freepascal.org/lists/fpc-devel/2013-March/031588.html.


My confused comment can be reformulated:  Delphi doesn't create object 
for each closure because there is no need to do it. But why many other 
languages should create object for each closure but Delphi need not ? 
Because Pascal allows to declare local variables only in beginning of 
routine. But many c-like languages allows to declare local variables in 
middle of routine. I will describe on example.


Imagine that you want to create many similar objects in loop like this:

=== example

type TWriter = class
   data: Integer;
   constructor Create(i: Integer);
   procedure Execute;
 end;
constructor TWriter.Create(i: Integer); begin data := i; end;
procedure TWriter.Execute; begin Writeln(data); end;

var i: Integer;
arr: array[1..10] of TWriter;
begin
  for i := 1 to 10 do
arr[i] := TWriter.Create(i);
  for i := 1 to 10 do
arr[i].Execute;
end.
===

=== output
1 2 3 4 5 6 7 8 9 10
===

If someone will try to make same trick using Delphi's anonymous 
methods(Delphi's implementation of closures) he may try to do this


=== wrong

  for i := 1 to 10 do
procArr[i] := procedure begin
Writeln(i);
  end;

  for j := 1 to 10 do
procArr[j]();
===

=== output
11 11 11 11 11 11 11 11 11 11
===

Why? Because all procedures from procArr captured variable 'i' by 
reference. They access same variable. So this is a problem to simply 
create "private" data for closure. But you can do it like this:


=== right

function Factory(data: Integer): TProc;
begin
  Result := procedure begin
  Writeln(data);
end;
end;

...

  for i := 1 to 10 do
procArr[i] := Factory(i);
  for j := 1 to 10 do
procArr[j]();

===

=== output
1 2 3 4 5 6 7 8 9 10
===

Just as expected.
Now about local variables and why in other languages simple creation of 
"private" variable for closure is not a problem.


=== perl
for (my $i = 0; $i < 10; ++$i) {
{
my $stored = $i;
$f[$i] = sub { printf $stored }
}
}

for (my $j = 0; $j < 10; ++$j) {
$f[$j]();
}
===

=== output
0123456789
===

This is works because:
  - each loop iteration creates new variable $stored
  - closure captures $stored
  - variable $stored is accessible only in it's declaring block { .. } 
; at end of loop iteration only closure will save link to it.


So Perl have to create new object for each closure because each closure 
may contains private d

Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Sven Barth

Am 05.03.2013 14:41, schrieb Mattias Gaertner:

Sven Barth  hat am 5. März 2013 um 14:27
geschrieben:

[...]
Please note that I wouldn't have choosen round brackets either
(potential conflicts with type casting)

?
Can you give an example?
Forget what I wrote... As I've written in my mail to Alexander, I've 
forgotten that we have the "specialize" as an introductory keyword.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Sven Barth

Am 05.03.2013 14:50, schrieb Alexander Klenin:

On Wed, Mar 6, 2013 at 12:27 AM, Sven Barth  wrote:

I don't know why the one who first implemented them chose them, but now the
reason is backwards compatibility.

Please note that I wouldn't have choosen round brackets either (potential
conflicts with type casting)

Is not "specialize" keyword there to prevent exactly this?

Right... I forgot :)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Alexander Klenin
On Wed, Mar 6, 2013 at 12:27 AM, Sven Barth  wrote:
> I don't know why the one who first implemented them chose them, but now the
> reason is backwards compatibility.
>
> Please note that I wouldn't have choosen round brackets either (potential
> conflicts with type casting)

Is not "specialize" keyword there to prevent exactly this?

> specialize SomeType with (Something)

I would like to propose a modification to one of the principles we brought up
in this thread: "prefer keywords to punctuation ... but not to the
point of becoming COBOL" :)

-- 
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Mattias Gaertner

Sven Barth  hat am 5. März 2013 um 14:27
geschrieben:
>[...]
> Please note that I wouldn't have choosen round brackets either
> (potential conflicts with type casting)

?
Can you give an example?

Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Sven Barth

Am 05.03.2013 14:23, schrieb Alexander Klenin:

On Wed, Mar 6, 2013 at 12:16 AM, Sven Barth  wrote:

SomeVar := SomeFunc - SomeType.SomeMethod *
SomeOtherType.SomeMethod;

=== example end ===

while this will be much easier to implement:

=== example begin ===

SomeVar := specialize SomeFunc - specialize
SomeType.SomeMethod * specialize
SomeOtherType.specialize SomeMethod;

=== example end ===

(though "specialize SomeType" and "specialize
SomeOtherType" are more likely to stay in type sections for
now...)


BTW, does anybody know why on earth the "sane" objFPC syntax still have
those angle brackets instead of normal round ones?

I don't know why the one who first implemented them chose them, but now 
the reason is backwards compatibility.


Please note that I wouldn't have choosen round brackets either 
(potential conflicts with type casting) but more something like this:


=== snippet begin ===

specialize SomeType with (Something)

=== snippet end ===

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Alexander Klenin
On Wed, Mar 6, 2013 at 12:16 AM, Sven Barth  wrote:
>
> SomeVar := SomeFunc - SomeType.SomeMethod *
> SomeOtherType.SomeMethod;
>
> === example end ===
>
> while this will be much easier to implement:
>
> === example begin ===
>
> SomeVar := specialize SomeFunc - specialize
> SomeType.SomeMethod * specialize
> SomeOtherType.specialize SomeMethod;
>
> === example end ===
>
> (though "specialize SomeType" and "specialize
> SomeOtherType" are more likely to stay in type sections for
> now...)
>

BTW, does anybody know why on earth the "sane" objFPC syntax still have
those angle brackets instead of normal round ones?

-- 
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Sven Barth

Am 05.03.2013 12:24, schrieb Marco van de Voort:

In our previous episode, Sven Barth said:

when Delphi announced them they had much more (you know of course).
That was more a prototype of generics. But inspite of that we did not
drop our own implementation.

Just to say one thing clear: I will NOT drop FPC's generic
implementation and I'll revert every commit that tries to do so, because
not only do we have to keep backwards compatibility, but the Delphi
syntax is a nightmare to parse.

But you need to anyway because of mode delphi, so what is the point?
Because in mode Delphi the following will not work for quite some time 
(because it is so damn hard to parse):


=== example begin ===

SomeVar := SomeFunc - SomeType.SomeMethod * 
SomeOtherType.SomeMethod;


=== example end ===

while this will be much easier to implement:

=== example begin ===

SomeVar := specialize SomeFunc - specialize 
SomeType.SomeMethod * specialize 
SomeOtherType.specialize SomeMethod;


=== example end ===

(though "specialize SomeType" and "specialize 
SomeOtherType" are more likely to stay in type sections for 
now...)


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Sven Barth

Am 05.03.2013 12:29, schrieb Alexander Klenin:

This is why I propose the following plan:

1) Implement Delphi-like anonymous functions syntax, without closures
2) Implement Delphi-like by-reference closures
3) Implement ObjFPC-specific named closures with explicit by-value/by
reference options
4) Implement ObjFPC-specific shortened syntax

Discussion of ObjFPC extension may continue while the implementation
of (1) and (2) is in progress.

I basically agree. Though for now anonymous functions should be either 
bound to mode Delphi or at least a modeswitch (enabled by default in 
mode Delphi and disabled everywhere else). [or maybe we should add such 
newer extensions to mode DelphiUnicode?] The type "reference to ..." 
should be available in either mode though (independantly of anonymous 
functions).


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Sven Barth

Am 05.03.2013 12:44, schrieb Michael Fuchs:

Am 05.03.2013 10:25, schrieb Michael Van Canneyt:

I've seen this before, and always been baffled by this. How can you
increment a "constant"? If you can, it is then a variable, no?


A leftover from the TP days. A typed constant acts as an initialized
variable.

You can disable this construct with:
http://www.freepascal.org/docs-html/prog/progsu42.html


This should be the default in ObjFpc mode.


Two words: backwards compatibility.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Marcos Douglas
On Tue, Mar 5, 2013 at 7:10 AM, Paul Ishenin  wrote:
> 05.03.13, 17:55, Sven Barth wrote:
>
>> @Paul: see? :)
>
>
> I see you, Graeme, Michael and probably some more 5-6 developers.

So now we have 7!  ;-)
I want to keep the language sane too.

Regards,
Marcos Douglas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Michael Fuchs

Am 05.03.2013 11:10, schrieb Paul Ishenin:

@Paul: see? :)


I see you, Graeme, Michael and probably some more 5-6 developers.


That is the problem with mailing lists. Not everybody sends a mail, just 
saying "+1 from me too". And so it could be "probably some more 500-600 
developers".


And btw: actual Delphi vs. ObjFPc -> +1 for ObjFpc from me ;)

Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Michael Fuchs

Am 05.03.2013 10:25, schrieb Michael Van Canneyt:

I've seen this before, and always been baffled by this. How can you
increment a "constant"? If you can, it is then a variable, no?


A leftover from the TP days. A typed constant acts as an initialized
variable.

You can disable this construct with:
http://www.freepascal.org/docs-html/prog/progsu42.html


This should be the default in ObjFpc mode.


Michael

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Marco van de Voort
In our previous episode, Alexander Klenin said:
> >> not only do we have to keep backwards compatibility, but the Delphi
> >> syntax is a nightmare to parse.
> >
> > But you need to anyway because of mode delphi, so what is the point?
> 
> It is hard to parse for humans as well as for the compiler.

That's a matter of taste. I'm not sb who in general favours terse notation,
but I don't really see the benefit of the FPC syntax for humans.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Alexander Klenin
On Tue, Mar 5, 2013 at 10:24 PM, Marco van de Voort  wrote:
>> Just to say one thing clear: I will NOT drop FPC's generic
>> implementation and I'll revert every commit that tries to do so, because
>> not only do we have to keep backwards compatibility, but the Delphi
>> syntax is a nightmare to parse.
>
> But you need to anyway because of mode delphi, so what is the point?

It is hard to parse for humans as well as for the compiler.

-- 
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Alexander Klenin
On Tue, Mar 5, 2013 at 9:10 PM, Paul Ishenin  wrote:
> 05.03.13, 17:55, Sven Barth wrote:
>
> I see you, Graeme, Michael and probably some more 5-6 developers.
>
The level of Delphi compatibility vs. syntax quality is, as always in
engineering,
a matter of compromise and cost/benefit analysis.
For example, and trying to return to the topic of this thread,
I think "embedded" anonymous functions should be implemented for both
Delphi and ObjFPC mode --
even if there will be better alternatives in ObjFPC.
This way, at least in one direction compatibility will be preserved,
while people preferring "pure Pascal" style will still be able to
ignore Delphi syntax in their FPC-only projects.
On the other hand, default closure behavior should perhaps be
implemented differently.
There are three choices for anonymous function without additional annotations:
1) No closure
2) By-reference closure
3) By-value closure

Delphi currently implements (2) which is inconsistent with nested
functions and introduces a subtle
and unexpected performance drop. I suggest (1) in ObjFPC mode, but (2)
in Delphi mode,
with additional modeswitch, as usual.

This is why I propose the following plan:

1) Implement Delphi-like anonymous functions syntax, without closures
2) Implement Delphi-like by-reference closures
3) Implement ObjFPC-specific named closures with explicit by-value/by
reference options
4) Implement ObjFPC-specific shortened syntax

Discussion of ObjFPC extension may continue while the implementation
of (1) and (2) is in progress.

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Marco van de Voort
In our previous episode, Sven Barth said:
> > when Delphi announced them they had much more (you know of course). 
> > That was more a prototype of generics. But inspite of that we did not 
> > drop our own implementation.
> Just to say one thing clear: I will NOT drop FPC's generic 
> implementation and I'll revert every commit that tries to do so, because 
> not only do we have to keep backwards compatibility, but the Delphi 
> syntax is a nightmare to parse.

But you need to anyway because of mode delphi, so what is the point?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Sven Barth

Am 05.03.2013 11:05, schrieb Henry Vermaak:

On Tue, Mar 05, 2013 at 10:12:04AM +0100, Michael Van Canneyt wrote:

You may think that Delphi is the best thing since sliced bread,
but not everyone thinks so.

And with the attitude of, e.g. Boian, we see that it's simply too hard
to please hard-core delphi fanboys.  They're all "take" and no "give".
I look forward to the day when the fpc developers will realise that
playing eternal catch-up is never going to work.


Somehow I hope we reach this day sooner than later...

There are several people on the list that do not like what Delphi is doing to
the pascal language. The way Embarcadero treats the Pascal Language
I am more and more going to this camp. More so with every release of
Delphi.

Much kudos to Sven for really trying to keep the language sane.


Thanks, I try my best :)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Bernd Mueller

Paul Ishenin wrote:


I remember author of Total Commander who had failed to port his project 
to FPC + Laz because of many incompatilities in both projects.


IMHO, you are not right. the 64-bit version seems to be written in 
FPC/Lazarus:


The string "FPC 2.5.1 [2011/12/03] for x86_64 - Win64" can be found in 
the binary.


Regards, Bernd.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Paul Ishenin

05.03.13, 17:55, Sven Barth wrote:


@Paul: see? :)


I see you, Graeme, Michael and probably some more 5-6 developers.

Best regards,
Paul Ishenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Henry Vermaak
On Tue, Mar 05, 2013 at 10:12:04AM +0100, Michael Van Canneyt wrote:
> You may think that Delphi is the best thing since sliced bread,
> but not everyone thinks so.

And with the attitude of, e.g. Boian, we see that it's simply too hard
to please hard-core delphi fanboys.  They're all "take" and no "give".
I look forward to the day when the fpc developers will realise that
playing eternal catch-up is never going to work.

> There are several people on the list that do not like what Delphi is doing to
> the pascal language. The way Embarcadero treats the Pascal Language
> I am more and more going to this camp. More so with every release of
> Delphi.

Much kudos to Sven for really trying to keep the language sane.

Henry
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Michael Van Canneyt



On Tue, 5 Mar 2013, Paul Ishenin wrote:


05.03.13, 17:12, Michael Van Canneyt wrote:


Of course we can, if you violate a basic rule: do not undo other peoples
work.


Can you imagine me or anybody other in FPC team who do so without total 
agreement?


I hope not :)


It does not split. It offers people the choice.


Again we see one thing from different sides. For me this is not a benefit but 
defect requires elimination.


This is your right.


This is the basis of open source: Having a choice.


Yes, but I'd love to see this choise not inside 1 project.


Since it is not your project to begin with, you'll have to learn to live with 
this choice.

Like I have to live with your implementations.

Live and let live.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Sven Barth

Am 05.03.2013 10:53, schrieb Graeme Geldenhuys:

On 2013-03-05 09:12, Michael Van Canneyt wrote:

You may think that Delphi is the best thing since sliced bread,
but not everyone thinks so.

There are several people on the list that do not like what Delphi is doing to
the pascal language.

+1000

I think Embarcadero is butchering the Object Pascal language. Stealing
ideas (and worse, the syntax) from other languages verbatim. They don't
put any thought in there language design like Borland did.

For that reason, I love FPC and the objfpc mode. ALL my products are
developer only in objfpc mode. The syntax is much cleaner and true to
Pascal.

@Paul: see? :)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Michael Van Canneyt



On Tue, 5 Mar 2013, Paul Ishenin wrote:



Think about component and applications developers who need to care about FPC 
and Delphi. Less incompatibilities FPC will have more 3rd party components 
and applications it will get.


For this, mode delphi exists.

I remember author of Total Commander who had failed to port his project to 
FPC + Laz because of many incompatilities in both projects.


I remember Fib+ developer who stoped his effort to port component to FPC 
after some found incompatibilities.


There is nothing good in incompatibilities.


There is no incompatibility. There is choice.

People who wish to port Delphi code should use {$mode delphi}.
And from what I see, people that come from Delphi automatically use $mode delphi. 
Good, that is what it is for.


I fully agree with you that Delphi mode should try and be as Delphi compatible 
as possible.

All that is being argued is that there must be the choice to have another mode where people 
that do not care or agree with Delphi, can implement things the way they think it should be done.


FPC is as old as Delphi. 
I think that gives us the right of speech and the right to voice our own opinion.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Paul Ishenin

05.03.13, 17:12, Michael Van Canneyt wrote:


Of course we can, if you violate a basic rule: do not undo other peoples
work.


Can you imagine me or anybody other in FPC team who do so without total 
agreement?



It does not split. It offers people the choice.


Again we see one thing from different sides. For me this is not a 
benefit but defect requires elimination.



This is the basis of open source: Having a choice.


Yes, but I'd love to see this choise not inside 1 project.


We do not deny you your work on Delphi mode.

We expect you not to deny us our work on objfpc mode.


Okay.

Best regards,
Paul Ishenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Graeme Geldenhuys
On 2013-03-05 09:12, Michael Van Canneyt wrote:
> You may think that Delphi is the best thing since sliced bread,
> but not everyone thinks so.
> 
> There are several people on the list that do not like what Delphi is doing to
> the pascal language.

+1000

I think Embarcadero is butchering the Object Pascal language. Stealing
ideas (and worse, the syntax) from other languages verbatim. They don't
put any thought in there language design like Borland did.

For that reason, I love FPC and the objfpc mode. ALL my products are
developer only in objfpc mode. The syntax is much cleaner and true to
Pascal.

Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Sven Barth

Am 05.03.2013 10:41, schrieb Paul Ishenin:

05.03.13, 17:14, Sven Barth wrote:


Just for your information: I will implement generic methods will full
requirement for "generic" and "specialize" in mode ObjFPC (and no, you
can't change my opinion on that).


Yes, I didn't expect my mails will suddenly change your opinion. And 
even if they would change there are enough fpc team members who will 
protected objfpc generics :) I only hope to stop duplicate 
implementation of other delphi features.


I won't remove your hope, but I'll also not do anything to fulfill it :P


And regarding backwards compatibility: we are not only talking about FPC
and Lazarus. There are enough people around that use FPC's generic
syntax and that alone is reason enough to keep it.


Enough - how much? 50 or 100 projects? What will be needed to make 
them work with dephi syntax? Remove word generic and specialize?


Once we support generic functions/procedures (which Delphi does not 
support) it will be more :)



Especially those that don't care about
Delphi compatibility. Also it seems that those that like to develop in
Delphi are the only ones complaining...


Think about component and applications developers who need to care 
about FPC and Delphi. Less incompatibilities FPC will have more 3rd 
party components and applications it will get.
For exactly this purpose we have the mode Delphi. And if something is 
not working there it's either a missing feature, a bug or something that 
we just plain refuse to support... (e.g. in Delphi you can have one set 
element multiple times in the same set constructor: [objectdef, 
objectdef, objectdef])


I remember author of Total Commander who had failed to port his 
project to FPC + Laz because of many incompatilities in both projects.




And some differences are by design. Think about resource string handling 
here. We might provide the LoadResString function/callback, but it's 
just a dummy, because FPC's resource strings work differently. The same 
for Lazarus: some differences are by design, because Lazarus is not 
fixed to the Windows platform (as a Lazarus developer you should know this).


I remember Fib+ developer who stoped his effort to port component to 
FPC after some found incompatibilities.


There is nothing good in incompatibilities.


As already wrote by Michael and me: it's not the purpose of mode ObjFPC 
to provide compatibility.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Paul Ishenin

05.03.13, 17:14, Sven Barth wrote:


Just for your information: I will implement generic methods will full
requirement for "generic" and "specialize" in mode ObjFPC (and no, you
can't change my opinion on that).


Yes, I didn't expect my mails will suddenly change your opinion. And 
even if they would change there are enough fpc team members who will 
protected objfpc generics :) I only hope to stop duplicate 
implementation of other delphi features.



And regarding backwards compatibility: we are not only talking about FPC
and Lazarus. There are enough people around that use FPC's generic
syntax and that alone is reason enough to keep it.


Enough - how much? 50 or 100 projects? What will be needed to make them 
work with dephi syntax? Remove word generic and specialize?



Especially those that don't care about
Delphi compatibility. Also it seems that those that like to develop in
Delphi are the only ones complaining...


Think about component and applications developers who need to care about 
FPC and Delphi. Less incompatibilities FPC will have more 3rd party 
components and applications it will get.


I remember author of Total Commander who had failed to port his project 
to FPC + Laz because of many incompatilities in both projects.


I remember Fib+ developer who stoped his effort to port component to FPC 
after some found incompatibilities.


There is nothing good in incompatibilities.

Best regards,
Paul Ishenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Sven Barth

Am 05.03.2013 10:20, schrieb Graeme Geldenhuys:

On 2013-03-04 20:33, Howard Page-Clark wrote:

You can simulate this in FPC as well as TP by using a local typed
constant. e.g.

function GetValue: integer;
const value: integer = 0;
begin
Inc(value);
Result:= value;
end;


I've seen this before, and always been baffled by this. How can you
increment a "constant"? If you can, it is then a variable, no?
In Turbo Pascal these typed constants were used as the poor man's 
visibility managment. You basically had a global variable that only that 
function (and nested ones) can access.


In Delphi the $J switch was introduced which is disabled by default, 
which means that typed constants are not writeable. You can nevertheless 
switch it on.


Note: The important point here is that it is a typed constant. And there 
typed constants and variables are technically the same (both are located 
in the initalized read/write area of the executable file), while true 
constants are either inserted directly into the code (ordinals, floating 
point values) or are located in a read only area of the executable 
(strings) [if the format does not support a readonly area they are 
located in the read/write one as well though].


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Michael Van Canneyt



On Tue, 5 Mar 2013, Graeme Geldenhuys wrote:


On 2013-03-04 20:33, Howard Page-Clark wrote:


You can simulate this in FPC as well as TP by using a local typed
constant. e.g.

function GetValue: integer;
const value: integer = 0;
begin
   Inc(value);
   Result:= value;
end;



I've seen this before, and always been baffled by this. How can you
increment a "constant"? If you can, it is then a variable, no?


A leftover from the TP days. 
A typed constant acts as an initialized variable.


You can disable this construct with:
http://www.freepascal.org/docs-html/prog/progsu42.html

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Graeme Geldenhuys
On 2013-03-04 20:33, Howard Page-Clark wrote:
> 
> You can simulate this in FPC as well as TP by using a local typed 
> constant. e.g.
> 
> function GetValue: integer;
> const value: integer = 0;
> begin
>Inc(value);
>Result:= value;
> end;


I've seen this before, and always been baffled by this. How can you
increment a "constant"? If you can, it is then a variable, no?


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Sven Barth

Am 05.03.2013 10:12, schrieb Michael Van Canneyt:
There are several people on the list that do not like what Delphi is 
doing to
the pascal language. The way Embarcadero treats the Pascal Language I 
am more and more going to this camp. More so with every release of 
Delphi.

As this thread clearly shows...

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Sven Barth

Am 05.03.2013 09:59, schrieb Paul Ishenin:

Just to say one thing clear: I will NOT drop FPC's generic
implementation and I'll revert every commit that tries to do so, because


Sven, relax - FPC is not your own project and not mine. We can't 
simple commit or revert what we want. 


I'm sorry that it sounded a bit harsh, but I consider the topics 
backwards compatibility and clean language design very serious. And 
parsing Delphi's syntax is everything, but not clean...





not only do we have to keep backwards compatibility, but the Delphi
syntax is a nightmare to parse.


Yes, it is hard to parse but anyway you need to implement it. So this 
argument if false. And regards backward compatibility - it is not too 
much places to fix: some in FPC itself and some in Lazarus components.


Just for your information: I will implement generic methods will full 
requirement for "generic" and "specialize" in mode ObjFPC (and no, you 
can't change my opinion on that).


And regarding backwards compatibility: we are not only talking about FPC 
and Lazarus. There are enough people around that use FPC's generic 
syntax and that alone is reason enough to keep it.





Mode ObjFPC is not for Delphi compatiblity. It's there to implement a
cleaner variant of the (Object) Pascal language (and Michael wrote), and
if that means higher maintenance burden, so be it.


That cleaner variants split pascal for nothing - to make 3-5 
developers happy.


There seem to be enough persons that use mode ObjFPC and its generics 
and seem to be happy about it. Especially those that don't care about 
Delphi compatibility. Also it seems that those that like to develop in 
Delphi are the only ones complaining... or do you hear from any MacPas 
developer that mode ObjFPC does not support "return", "c" or "$ifc"?


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Michael Van Canneyt



On Tue, 5 Mar 2013, Paul Ishenin wrote:


05.03.13, 16:30, Sven Barth wrote:


Just to say one thing clear: I will NOT drop FPC's generic
implementation and I'll revert every commit that tries to do so, because


Sven, relax - FPC is not your own project and not mine. We can't simple 
commit or revert what we want.


Of course we can, if you violate a basic rule: do not undo other peoples work.


not only do we have to keep backwards compatibility, but the Delphi
syntax is a nightmare to parse.


Yes, it is hard to parse but anyway you need to implement it. So this 
argument if false. And regards backward compatibility - it is not too much 
places to fix: some in FPC itself and some in Lazarus components.



Mode ObjFPC is not for Delphi compatiblity. It's there to implement a
cleaner variant of the (Object) Pascal language (and Michael wrote), and
if that means higher maintenance burden, so be it.


That cleaner variants split pascal for nothing - to make 3-5 developers 
happy.


It does not split. It offers people the choice.

This is the basis of open source: Having a choice.

You may think that Delphi is the best thing since sliced bread,
but not everyone thinks so.

There are several people on the list that do not like what Delphi is doing to
the pascal language. The way Embarcadero treats the Pascal Language I am more 
and more going to this camp. More so with every release of Delphi.


You must live with this fact, as I must live with your love of Delphi.

We do not deny you your work on Delphi mode.

We expect you not to deny us our work on objfpc mode.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Paul Ishenin

05.03.13, 16:30, Sven Barth wrote:


Just to say one thing clear: I will NOT drop FPC's generic
implementation and I'll revert every commit that tries to do so, because


Sven, relax - FPC is not your own project and not mine. We can't simple 
commit or revert what we want.



not only do we have to keep backwards compatibility, but the Delphi
syntax is a nightmare to parse.


Yes, it is hard to parse but anyway you need to implement it. So this 
argument if false. And regards backward compatibility - it is not too 
much places to fix: some in FPC itself and some in Lazarus components.



Mode ObjFPC is not for Delphi compatiblity. It's there to implement a
cleaner variant of the (Object) Pascal language (and Michael wrote), and
if that means higher maintenance burden, so be it.


That cleaner variants split pascal for nothing - to make 3-5 developers 
happy.


Best regards,
Paul Ishenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Michael Van Canneyt



On Tue, 5 Mar 2013, Sven Barth wrote:


Am 05.03.2013 07:56, schrieb Paul Ishenin:

05.03.13, 14:10, Sven Barth wrote:


ObjFPC mode is not compatible with mode Delphi, because of conscious
decisions. Think for example about the "@" for procedure variable
assignments here or the use of symbolic operator names for overload
declarations, instead of words like Delphi did it. And generics are a
further example.


And I would left (if needed) only those minimal differences. Or even tried 
to reduce (removed own generics implementation and left only Delphi 
compatible). In any case I would not add more incompatibilities.


Many times the main point to have incompatibilites was: "We implemented it 
earlier". But regards generics how we implemeneted it earlier? Even now 
they have some bugs/missing features. And in 2009 when Delphi announced 
them they had much more (you know of course). That was more a prototype of 
generics. But inspite of that we did not drop our own implementation.
Just to say one thing clear: I will NOT drop FPC's generic implementation and 
I'll revert every commit that tries to do so, because not only do we have to 
keep backwards compatibility, but the Delphi syntax is a nightmare to parse.


Mode ObjFPC is not for Delphi compatiblity. It's there to implement a cleaner 
variant of the (Object) Pascal language (and Michael wrote), and if that 
means higher maintenance burden, so be it. Somewhen in the future we should 
do a rewrite of the parser anyway and then we can learn from the problems we 
faced currently and implement it in a way that we can easily extend the 
language with different implementations (just like was done for the backend).


+1

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Michael Van Canneyt



On Tue, 5 Mar 2013, Paul Ishenin wrote:


05.03.13, 15:57, Michael Van Canneyt wrote:

With such an attitude you should remove objfpc (and perhaps all
non-delphi modes) alltogether, and rename Free Pascal to Free Delphi.


The situation with FPC and Delphi is very like to what had happened with 
browsers. Every had it own vision of CSS, JS and HTML. Currently then finally 
understood that these dirrences are bad.


You piched a wrong comparison. They are still different in all browsers. 
Each browser has its own extensions of these "standards" as any web developer will tell you.
There is some common ground (and even this is sometimes interpreted differently), 
but that is it.


So if I could I would organaize some forum between Delphi and FPC developers 
where all new features before been implemented had been discussed first and 
if accepted nobody could implement it different. I tried to contact with some 
delphi team members on their forum on twitter and on some blogs but without 
result.


I do not believe they will ever do this. Why would they want to ?
They (think that they) rule the Pascal community. 
They do not care a fig for Lazarus/FPC.


And that is why we have objfpc mode.

Delphi mode is 'Object pascal according to Embarcadero'

ObjFPC mode is 'Object Pascal according to Free Pascal'

There is nothing wrong with having ObjFPC mode, and the bigger the differences 
are, the better.

The only thing it costs you is some extra cases in parsing, so no maintenance whatsoever. 
The rest of the compiler remains the same, as the functionality is equal.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Sven Barth

Am 05.03.2013 07:56, schrieb Paul Ishenin:

05.03.13, 14:10, Sven Barth wrote:


ObjFPC mode is not compatible with mode Delphi, because of conscious
decisions. Think for example about the "@" for procedure variable
assignments here or the use of symbolic operator names for overload
declarations, instead of words like Delphi did it. And generics are a
further example.


And I would left (if needed) only those minimal differences. Or even 
tried to reduce (removed own generics implementation and left only 
Delphi compatible). In any case I would not add more incompatibilities.


Many times the main point to have incompatibilites was: "We 
implemented it earlier". But regards generics how we implemeneted it 
earlier? Even now they have some bugs/missing features. And in 2009 
when Delphi announced them they had much more (you know of course). 
That was more a prototype of generics. But inspite of that we did not 
drop our own implementation.
Just to say one thing clear: I will NOT drop FPC's generic 
implementation and I'll revert every commit that tries to do so, because 
not only do we have to keep backwards compatibility, but the Delphi 
syntax is a nightmare to parse.


Mode ObjFPC is not for Delphi compatiblity. It's there to implement a 
cleaner variant of the (Object) Pascal language (and Michael wrote), and 
if that means higher maintenance burden, so be it. Somewhen in the 
future we should do a rewrite of the parser anyway and then we can learn 
from the problems we faced currently and implement it in a way that we 
can easily extend the language with different implementations (just like 
was done for the backend).


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-05 Thread Paul Ishenin

05.03.13, 15:57, Michael Van Canneyt wrote:

With such an attitude you should remove objfpc (and perhaps all
non-delphi modes) alltogether, and rename Free Pascal to Free Delphi.


The situation with FPC and Delphi is very like to what had happened with 
browsers. Every had it own vision of CSS, JS and HTML. Currently then 
finally understood that these dirrences are bad.


So if I could I would organaize some forum between Delphi and FPC 
developers where all new features before been implemented had been 
discussed first and if accepted nobody could implement it different. I 
tried to contact with some delphi team members on their forum on twitter 
and on some blogs but without result.


Regards FPC, I would indeed remove FPC mode. Those who need it can use 
FPC 2.6. I would also minimize the difference between objfpc and delphi 
modes.


Best regards,
Paul Ishenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Michael Van Canneyt



On Tue, 5 Mar 2013, Paul Ishenin wrote:


05.03.13, 14:10, Sven Barth wrote:


ObjFPC mode is not compatible with mode Delphi, because of conscious
decisions. Think for example about the "@" for procedure variable
assignments here or the use of symbolic operator names for overload
declarations, instead of words like Delphi did it. And generics are a
further example.


And I would left (if needed) only those minimal differences. Or even tried to 
reduce (removed own generics implementation and left only Delphi compatible). 
In any case I would not add more incompatibilities.


With such an attitude you should remove objfpc (and perhaps all non-delphi modes) 
alltogether, and rename Free Pascal to Free Delphi.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Michael Van Canneyt



On Tue, 5 Mar 2013, Sven Barth wrote:



Am 05.03.2013 04:55 schrieb "Paul Ishenin" :
>
> 04.03.2013 18:29, Marco van de Voort wrote:
>
>> I chose the latter. Compatibility. All the way. No compromise.
>>
>> Is it pure? No. Is it perfect? No. Is it better than the alternative? Yes.
>>
>> Currently FPC is much dirtier than Delphi if only because it has two
>> implementations for everything.
>
>
> I'm totally agree. 2 implementations complicates the compiler and complicates 
the use of the compiler. Component developers
and those who plant to port their delphi projects will not use objfpc mode if 
it will not be delphi compatible.


Of course not.

The whole idea of objfpc mode is that it is *not* Delphi compatible.
If it had to be Delphi compatible, we would not have had to introduce it.

It aims to give the same functionality Delphi offers, but implemented in 
what FPC developers consider a proper 'Object Pascal' way.




ObjFPC mode is not compatible with mode Delphi, because of conscious decisions. Think for 
example about the "@" for procedure
variable assignments here or the use of symbolic operator names for overload 
declarations, instead of words like Delphi did it.
And generics are a further example.


Exactly.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Michael Van Canneyt



On Mon, 4 Mar 2013, Boian Mitov wrote:


I have never attempted to use it in wine.
It is at current for Windows only, and is a prerelease.


A pity.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Paul Ishenin

05.03.13, 14:10, Sven Barth wrote:


ObjFPC mode is not compatible with mode Delphi, because of conscious
decisions. Think for example about the "@" for procedure variable
assignments here or the use of symbolic operator names for overload
declarations, instead of words like Delphi did it. And generics are a
further example.


And I would left (if needed) only those minimal differences. Or even 
tried to reduce (removed own generics implementation and left only 
Delphi compatible). In any case I would not add more incompatibilities.


Many times the main point to have incompatibilites was: "We implemented 
it earlier". But regards generics how we implemeneted it earlier? Even 
now they have some bugs/missing features. And in 2009 when Delphi 
announced them they had much more (you know of course). That was more a 
prototype of generics. But inspite of that we did not drop our own 
implementation.


Regards for-in loop. To add it to objfpc mode I had to add 'enumerator' 
keyword. Who uses it? 1.5 developers who wants to see pascal clean?


Besides that I'm not against own features like string case or '+=' 
operations but I strongly against 2 implementations of 1 feature: one to 
be delphi compatible, one to satisfy few people from pascal community.


Best regards,
Paul Ishenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Sven Barth
Am 05.03.2013 04:55 schrieb "Paul Ishenin" :
>
> 04.03.2013 18:29, Marco van de Voort wrote:
>
>> I chose the latter. Compatibility. All the way. No compromise.
>>
>> Is it pure? No. Is it perfect? No. Is it better than the alternative?
Yes.
>>
>> Currently FPC is much dirtier than Delphi if only because it has two
>> implementations for everything.
>
>
> I'm totally agree. 2 implementations complicates the compiler and
complicates the use of the compiler. Component developers and those who
plant to port their delphi projects will not use objfpc mode if it will not
be delphi compatible.

ObjFPC mode is not compatible with mode Delphi, because of conscious
decisions. Think for example about the "@" for procedure variable
assignments here or the use of symbolic operator names for overload
declarations, instead of words like Delphi did it. And generics are a
further example.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Paul Ishenin

04.03.2013 18:29, Marco van de Voort wrote:


I chose the latter. Compatibility. All the way. No compromise.

Is it pure? No. Is it perfect? No. Is it better than the alternative? Yes.

Currently FPC is much dirtier than Delphi if only because it has two
implementations for everything.


I'm totally agree. 2 implementations complicates the compiler and 
complicates the use of the compiler. Component developers and those who 
plant to port their delphi projects will not use objfpc mode if it will 
not be delphi compatible.


Best regards,
Paul Ishenin

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin

On 04/03/2013 22:16, Sven Barth wrote:


> The above is NOT an anonymous function. It is a reference to a term.
> I am not voting for it, but IF it was done, then it should have its 
own keyword.

>
> It would not allow for var, type or anything (and it will only work 
for functions, not procedures.)

>a.sort(LambdaTerm TMyCompare do x > y)
> or
>a.sort(TermRef TMyCompare(x > y) )

This is basically what my idea behind the lambs syntax was: only one 
expression or statement and no variable, type or constant 
declarations. And for more complex use case there are either Delphi's 
anonymous functions or FPC's nested procedures/functions.




Ok, so then it is important, that they are distinguished. Starting with 
their own name. We MUST NOT call them anonymous functions. (despite the 
do construct a function. But they are not, because the skip the  
Result:= part and other)


Technically they are a subset:
1- like a function, they have a result
2- like a function the have zero, 1 or more params
3- not like a functions, they can not have var or out param
  Well you can construct cases were they are possible:  (* Result := *) 
1 + Foo(VarParam);

  But I think they should not be allowed
4- There body must always contain a RHS term/expression
  This also results in that the can only be passed for functions
5- begin end is not allowed (would not be an RHS

About 4) If you want procedures to, then we can not use an RHS, because 
a procedure needs a full statement in the body.
That would mean functions would have to include the "Result :=". There 
is no way of smart detection, because a function can also sot the result 
by doing "CallFoo(Result)" (CallFoo has an out param)

It is either or, but no mixture.
Even if it goes for proceddure style, 5 should still be considered.



> anonymous function, then would *always* require
>a. sort( Function; prototype TMyCompare; [var ...] begin ... end )
>
> the protopybe (modifier) could work for named procedures too. (THey 
would be required NOT to have any params)

>   Function Foo; prototype TMyCompare;
>   [var ...]
>   begin ... end

Ah! Now with the named example I understand the use of the ";" after 
the "function"...




I think using a modifier is the best way to specify the parameter template.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Boian Mitov

I have never attempted to use it in wine.
It is at current for Windows only, and is a prerelease.
Here are however couple of very old snapshots. They are ~2 months old and 
miss a lot of new features, but will give you idea.


http://www.mitov.com/OpenWireIDENewRunning.png
http://www.mitov.com/OpenWireIDENew1.png

Plan to release it in Beta in the next 2-3 weeks.

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Michael Van Canneyt 
Sent: Monday, March 04, 2013 1:39 PM 
To: FPC developers' list 
Subject: Re: [fpc-devel] Delphi anonymous methods 


home: >wine OpenWireIDE.exe

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Boian Mitov
Cool :-).
BTW: When you implement it, please consider making it available for attributes!
The Delphi version really sucks in this :-( .
I have not been able to do things like:

[TComponentDialog( 
procedure( AInstance : TComponent)
begin
   TMyComponnt( AInstance ).ShowDialog();
end
]
TMyComponnt = class( TComponent )
public
  procedure ShowDialog();
end;

This could have eliminated a full source file, and replaced it with 3 lines :-( 
. I really hate the half baked attribute and anonymous methods in Delphi :-( .

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---


From: Sven Barth 
Sent: Monday, March 04, 2013 2:19 PM
To: fpc-devel@lists.freepascal.org 
Subject: Re: [fpc-devel] Delphi anonymous methods

We'll implement features of Delphi anyway for compatibility. So why not use the 
implementation of it, provide some nice Pascal-style syntax for it and allow 
FPC users to usr the feature in non-Delphi modes as well. :)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Boian Mitov
I actually looked at it few years ago. I also bought one of the Digital Mars 
CDs and still have it.
It was at the time garbage collected, and this is a major No No in my book ;-) .

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---


From: Roberto P. 
Sent: Monday, March 04, 2013 2:06 PM
To: FPC developers' list 
Subject: Re: [fpc-devel] Delphi anonymous methods

FPC is really an exciting and always improving language/project, but IMHO if 
you stretch out too much from the Pascal origin and "general frame", then 
people will eventually get lost and abandone it. 

By the way, given your tastes, you might want to have a look a the D language.
It's my favorite second choice :-)

R#___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Sven Barth
Am 04.03.2013 23:06 schrieb "Roberto P." :
>
> FPC is really an exciting and always improving language/project, but IMHO
if you stretch out too much from the Pascal origin and "general frame",
then people will eventually get lost and abandone it.

We'll implement features of Delphi anyway for compatibility. So why not use
the implementation of it, provide some nice Pascal-style syntax for it and
allow FPC users to usr the feature in non-Delphi modes as well. :)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Sven Barth
Am 04.03.2013 22:41 schrieb "Martin" :
>
> On 04/03/2013 19:16, Alexander Klenin wrote:
>>>
>>> See above. The omission "of Result :=" is IMHO not desirable.
>>
>> Are you sure? Note that *any* useful single-statement function will
>> start exactly like this
>
> If a = x then Result := 4 else Result := 5;
>
> Single statement, but starts different.  And is useful.
>
> But that isn't why I replied again.
>
> Reading the shortened version versus the full anonymous procedure (with
var, const, type) and I realized, that thi's a 2 entirely different
things.
>
> The above is NOT an anonymous function. It is a reference to a term.
> I am not voting for it, but IF it was done, then it should have its own
keyword.
>
> It would not allow for var, type or anything (and it will only work for
functions, not procedures.)
>a.sort(LambdaTerm TMyCompare do x > y)
> or
>a.sort(TermRef TMyCompare(x > y) )

This is basically what my idea behind the lambs syntax was: only one
expression or statement and no variable, type or constant declarations. And
for more complex use case there are either Delphi's anonymous functions or
FPC's nested procedures/functions.

> anonymous function, then would *always* require
>a. sort( Function; prototype TMyCompare; [var ...] begin ... end )
>
> the protopybe (modifier) could work for named procedures too. (THey would
be required NOT to have any params)
>   Function Foo; prototype TMyCompare;
>   [var ...]
>   begin ... end

Ah! Now with the named example I understand the use of the ";" after the
"function"...

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Roberto P.
FPC is really an exciting and always improving language/project, but IMHO
if you stretch out too much from the Pascal origin and "general frame",
then people will eventually get lost and abandone it.

By the way, given your tastes, you might want to have a look a the D
language.
It's my favorite second choice :-)

R#


2013/3/4 Boian Mitov 

> Correct :-) .
> Now back to running it ;-) .
> Cheers!
> See what I am cooking next:
>
> http://www.mitov.com/**OpenWireIDE.zip<http://www.mitov.com/OpenWireIDE.zip>
>
> Enjoy! :-D
>
>
> With best regards,
> Boian Mitov
>
> --**-
> Mitov Software
> www.mitov.com
> --**-
> -Original Message- From: Michael Van Canneyt Sent: Monday, March
> 04, 2013 12:41 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi
> anonymous methods
>
>
> On Mon, 4 Mar 2013, Boian Mitov wrote:
>
> Do not get me wrong, I do not ask you to change your decision or your code.
> You have a business to run, and this should be your primary concern.
>
> __**_
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/**mailman/listinfo/fpc-devel<http://lists.freepascal.org/mailman/listinfo/fpc-devel>
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin

On 04/03/2013 19:16, Alexander Klenin wrote:

See above. The omission "of Result :=" is IMHO not desirable.

Are you sure? Note that *any* useful single-statement function will
start exactly like this

If a = x then Result := 4 else Result := 5;

Single statement, but starts different.  And is useful.

But that isn't why I replied again.

Reading the shortened version versus the full anonymous procedure (with 
var, const, type) and I realized, that thi's a 2 entirely different 
things.


The above is NOT an anonymous function. It is a reference to a term.
I am not voting for it, but IF it was done, then it should have its own 
keyword.


It would not allow for var, type or anything (and it will only work for 
functions, not procedures.)

   a.sort(LambdaTerm TMyCompare do x > y)
or
   a.sort(TermRef TMyCompare(x > y) )

anonymous function, then would *always* require
   a. sort( Function; prototype TMyCompare; [var ...] begin ... end )

the protopybe (modifier) could work for named procedures too. (THey 
would be required NOT to have any params)

  Function Foo; prototype TMyCompare;
  [var ...]
  begin ... end

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Michael Van Canneyt



On Mon, 4 Mar 2013, Boian Mitov wrote:


Correct :-) .
Now back to running it ;-) .
Cheers!
See what I am cooking next:

http://www.mitov.com/OpenWireIDE.zip


home: >wine OpenWireIDE.exe
p11-kit: couldn't load module: 
/usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: 
/usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared 
object file: No such file or directory
p11-kit: couldn't load module: 
/usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: 
/usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared 
object file: No such file or directory
fixme:storage:create_storagefile Storage share mode not implemented.
err:mscoree:LoadLibraryShim error reading registry key for installroot
err:mscoree:LoadLibraryShim error reading registry key for installroot
err:mscoree:LoadLibraryShim error reading registry key for installroot
err:mscoree:LoadLibraryShim error reading registry key for installroot
err:mscoree:LoadLibraryShim error reading registry key for installroot
err:mscoree:LoadLibraryShim error reading registry key for installroot
fixme:iphlpapi:NotifyAddrChange (Handle 0xebe8cc, overlapped 0xebe8b0): stub
p11-kit: couldn't load module: 
/usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: 
/usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared 
object file: No such file or directory
wine: configuration in '/home/michael/.wine' has been updated.
p11-kit: couldn't load module: 
/usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: 
/usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared 
object file: No such file or directory
fixme:process:GetLogicalProcessorInformation ((nil),0x32fde4): stub
fixme:gdiplus:GdipSetPathGradientSurroundColorsWithCount not implemented
^Z

:(

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Boian Mitov

Correct :-) .
Now back to running it ;-) .
Cheers!
See what I am cooking next:

http://www.mitov.com/OpenWireIDE.zip

Enjoy! :-D

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Michael Van Canneyt 
Sent: Monday, March 04, 2013 12:41 PM 
To: FPC developers' list 
Subject: Re: [fpc-devel] Delphi anonymous methods 




On Mon, 4 Mar 2013, Boian Mitov wrote:

Do not get me wrong, I do not ask you to change your decision or your code.
You have a business to run, and this should be your primary concern.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin

On 04/03/2013 19:16, Alexander Klenin wrote:

function NAME(PARAMS): RETURNTYPE as EXPRESSION

IMHO that is not a good idea. It adds an additional construct, that every
reader must know how to read. It does not add/save enough to be needed.

I agree, it is borderline, and needs to be additionally justified.
I believe that for each feature, there is a threshold for the baroqueness of
syntax required to use it which separates "obscure" from "simple and
understandable".
The main barrier for understanding code is not actually the number of
language constructs involved -- they are way too few compared to,
say, number of procedures in any non-trivial library.
The main barrier is the amount of effort required to see the programmers intent
while looking at a given piece of code.
For example (still using "lambda" syntax here to not muddle the issue,
I'll discuss your alternatives to "lambda" below):

// Task: Select five largest even numbers from the array:

// (0) Theoretically possible with type inference:
AIntArray.Filter(lambda X div 2 = 0).Sort(lambda X > Y).Take(5);
How is that possible? In "lambda X > Y " how does the compiler know, if 
X or Y is the first param?




// (1) My proposal
AIntArray.Filter(lambda TIntFilter as X div 2 = 0).Sort(lambda TIntCmp
as X > Y).Take(5);
And that is a good example *against* anonymous functions. Even with some 
c# background (and it does remind me of it / maybe general dotNet), I 
had to read it several times.
Sure, if it was highlighted it might be easier to find the keywords 
lambda/as and to know where the expression (the truncated "result :=" 
statement starts.




// (2) Without "as"
AIntArray.
   Filter(lambda TIntFilter; begin Result := X div 2 = 0 end).
   Sort(lambda TIntCmpl; begin Result := X > Y; end).Take(5);


You comparison is tainted. the begin/end are not needed. Though, I 
actually would like them required. Well at least the end. The lambda 
might serve as the opening.


AIntArray.
  Filter(lambda TIntFilter; Result := X div 2 = 0 end).
  Sort(lambda TIntCmpl; Result := X > Y; end).Take(5);

And that is of course because of your preference for keyword over typecast. 
Though you are right, even in a typecast a keyword would be good to indicate 
this code is not executed right away.

  AIntArray.
  Filter(TIntFilter(lambda Result := X div 2 = 0 end).
  Sort(TIntCmpl(lambda Result := X > Y end).Take(5);

Then a none type casted lambda could return a "procedure();", no params, no 
result.


// (4) Without anonymous functions:
function IsEven(X: Integer): Boolean; begin
   Result := X div 2 = 0;
end;
function IsGreaterThan(X, Y: Integer): Boolean; begin
   Result := X > Y;
end;
// ... possibly a lot of code here
AIntArray.Filter(@IsEven).Sort(@IsGreaterThan).Take(5);
And the actual fitter/sort line is so much easier to read. Really, so 
much easier...



As you can see, there is a spectrum of expressive power vs language simplicity.
It is debatable at which position of the spectrum Pascal should be,
but my opinion is that (4) is way too weak, (0) is probably too strong,
and (1) is easier to read then (2), (3) or (4) for any reasonably
literate programmer,

actually from a point of readability
 TIntCmpl(lambda Result := X > Y end
looks easiest to me. WIthin the typecast, you have only an opening 
/closing keyword. The rest is the code. No distraction






We could also use the new, have a constructor for everything (TArray.Create)
style. Personally, the idea appals me, but
TVisitor.Create(Result := x + 5)

I actually dislike this syntax even for arrays.

As I said: the idea appals me


Another way to avoid the "as"
   lambda(TVisitor)  end
lambda acts as "begin" to the block, so there always must be an end.

Why not also omit "end" then? Just say that "lambda" must be followed
by a single statement,
No Pascal is verbose. It must be a proper block. TO easy to misread 
otherwise.
 It does not have to finish with end, there could be another keyword. 
(Like in repeat until pair).


If there is no block
  Foo(lambda TFunc x = a, lambda TFunc yAnd if (another of those I personally do not like it) tuples will come, 
then

Foo(lambda TFunc x = (a, lambda TFunc y
then for the case of many statements, "begin..end" should be used like
in normal blocks.
The only problem is with local declarations, but I guess it is
possible to disambiguate
based on "var", "const" and "type" keywords appearing after "lambda".

Argh yes, I hadn't thougt of that yet.

Well then that just makes it an even bigger monstrosity.
I am not going to think about that now. To much work for something that 
I do not want in first





See above. The omission "of Result :=" is IMHO not desirable.

Are you sure? Note that *any* useful single-statement function will
start exactly like this
(strictly speaking, it could be also be call to "exit", but obviously
it makes no difference).
And single-statement functions are the most important use case for
anonymous functions --
basically, if 

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Michael Van Canneyt



On Mon, 4 Mar 2013, Boian Mitov wrote:


Then why do you think I am wasting my time writing all this?


I should be asking this to you :-)


I really want to support Lazarus, but that is not even remotely possible 
today.


That says it all.

Delphi doesn't support these 'new features' that long either, and you admit working for 15 years 
with Delphi. So at some point you made a decision to start using new features. Most likely, it 
was not necessary to use them. It may have made some things easier. Maybe you wanted to support 
some C# stuff - I do not know the reasons.


In each case, that is when you took the decision not to support Lazarus/FPC, 
which did not have these features, and which never promised to have them.


And it is also why I do not think that adding these features today will change 
your decision.
Because it is this today, that tomorrow. We are playing catch-up forever anyway.

Do not get me wrong, I do not ask you to change your decision or your code.
You have a business to run, and this should be your primary concern.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Howard Page-Clark

On 04/03/13 6:34, waldo kitty wrote:


i'm trying to understand what you mean by

 > Pascal don't allows to create static variables inside function like
in c-like
 > languages.

i've done something that i think is what you speak of but it was in
Borland's Turbo Pascal... at least TP6... i don't remember how we did it
though and can't find any sample code in my library :(


You can simulate this in FPC as well as TP by using a local typed 
constant. e.g.


function GetValue: integer;
const value: integer = 0;
begin
  Inc(value);
  Result:= value;
end;

Successive calls to GetValue() will return 1, 2, 3 etc.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Boian Mitov

Then why do you think I am wasting my time writing all this?
I really want to support Lazarus, but that is not even remotely possible 
today.
I have well over 4 mln. lines of code and I need to support Delphi and C++ 
Builder with it.
I will surely not abandon my current customer base just to rewrite 
everything for Lazarus only, and since Lazarus does not support DLL based 
packages, I will have to stop supporting my C++ and .NET customers as well. 
In essence I will have to kill my business just to support Lazarus. That 
would be foolish business decision, both for me and my employees, and 
customers.
However if ever Lazarus gets attributes, extended RTTI, anonymous methods 
and dynamic packages at least in Windows, then I surely will invest more 
time and money in it (I spent a lot of time and money on it few years ago, 
before giving up.). I know how to take a risk, but I also know when it is 
foolish to take the risk.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Michael Van Canneyt

Sent: Monday, March 04, 2013 11:12 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods



On Mon, 4 Mar 2013, Boian Mitov wrote:

But I seriously doubt that this has to do with missing anonymous functions 
in

a delphi-compatible form.

I also doubt that adding anonymous functions would make you change your 
mind.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Alexander Klenin
On Tue, Mar 5, 2013 at 3:34 AM, Martin  wrote:
> On 04/03/2013 16:05, Alexander Klenin wrote:
>>
>> Anonymous functions (with good syntax, of course) fall in this category.
>> The world recognized that fact -- rather slowly, to be sure, but
>> remember that "while"s and "for"s
>> also took decades to be accepted as standard constructs.
>
>  I am not going to ask for proof of this statement
I've made two statements here:
1) Anonymous functions are considered essential part of any modern
programming language.
  For a proof, look at any modern programming language :)
  Or, to save time, here is a list:
  http://en.wikipedia.org/wiki/Anonymous_function#List_of_languages
2) "while" loop took a long time to be invented and widely accepted.
  First high-level programming languages, like FORTRAN and COBOL,
created in 1950s,
  did not have it. First more-or-less widely known language to support
Algol, which came about 1960.
  However, Algol did not became used in practice, and the notion of
  structured programming was widely debated until the 1970s.
  For example, FORTRAN 77 still did not have "while" loop,
  it was considered an extension implemented by some compilers,
  and it was a standard recommendation to rewrite "while" using "if" and "goto"
  to increase code portability.
  So it took about 10 to 20 years for "while" loops to emerge and
become commonplace.
  I must note that the part of my statement about "for" is totally wrong --
  I just typed without thinking. Of course, FORTRAN had "DO" loops
right from the beginning.

>>function NAME(PARAMS): RETURNTYPE as EXPRESSION
>
> IMHO that is not a good idea. It adds an additional construct, that every
> reader must know how to read. It does not add/save enough to be needed.

I agree, it is borderline, and needs to be additionally justified.
I believe that for each feature, there is a threshold for the baroqueness of
syntax required to use it which separates "obscure" from "simple and
understandable".
The main barrier for understanding code is not actually the number of
language constructs involved -- they are way too few compared to,
say, number of procedures in any non-trivial library.
The main barrier is the amount of effort required to see the programmers intent
while looking at a given piece of code.
For example (still using "lambda" syntax here to not muddle the issue,
I'll discuss your alternatives to "lambda" below):

// Task: Select five largest even numbers from the array:

// (0) Theoretically possible with type inference:
AIntArray.Filter(lambda X div 2 = 0).Sort(lambda X > Y).Take(5);

// (1) My proposal
AIntArray.Filter(lambda TIntFilter as X div 2 = 0).Sort(lambda TIntCmp
as X > Y).Take(5);

// (2) Without "as"
AIntArray.
  Filter(lambda TIntFilter; begin Result := X div 2 = 0 end).
  Sort(lambda TIntCmpl; begin Result := X > Y; end).Take(5);

// (3) Without "lambda"
AIntArray.
  Filter(function (X: Integer): Boolean; begin Result := X div 2 = 0 end).
  Sort(function (X, Y: Integer): Boolean; begin Result := X > Y; end).Take(5);

// (4) Without anonymous functions:
function IsEven(X: Integer): Boolean; begin
  Result := X div 2 = 0;
end;
function IsGreaterThan(X, Y: Integer): Boolean; begin
  Result := X > Y;
end;
// ... possibly a lot of code here
AIntArray.Filter(@IsEven).Sort(@IsGreaterThan).Take(5);

As you can see, there is a spectrum of expressive power vs language simplicity.
It is debatable at which position of the spectrum Pascal should be,
but my opinion is that (4) is way too weak, (0) is probably too strong,
and (1) is easier to read then (2), (3) or (4) for any reasonably
literate programmer,
regardless of whether or not he knows about details of anonymous
functions in Pascal.

> We could also use the new, have a constructor for everything (TArray.Create)
> style. Personally, the idea appals me, but
>TVisitor.Create(Result := x + 5)
I actually dislike this syntax even for arrays.
Nevertheless, I agree that this could be good idea, except it works only for
anonymous functions, thus losing the advantages for named ones.

> Another way to avoid the "as"
>   lambda(TVisitor)  end
> lambda acts as "begin" to the block, so there always must be an end.
Why not also omit "end" then? Just say that "lambda" must be followed
by a single statement,
then for the case of many statements, "begin..end" should be used like
in normal blocks.
The only problem is with local declarations, but I guess it is
possible to disambiguate
based on "var", "const" and "type" keywords appearing after "lambda".
My intention with the designated "as" keyword is to reduce the need
for look-ahead
in a grammar (which, btw, can also be considered one of "Pascal principles").
But certainly, is the "as" keyword can always be inferred from context,
then I am all for omitting it.

> See above. The omission "of Result :=" is IMHO not desirable.
Are you sure? Note that *any* useful single-statement function will
start exactly like this
(strictly speaking, it could 

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Michael Van Canneyt



On Mon, 4 Mar 2013, Boian Mitov wrote:


  Hi Michael,

Thank you!
I actually have more experience in C++ than in Delphi. I have been using 
Delphi only for ~15 years, where my active C++ experience dates back to 1990, 
and I actively develop in C++ and C# on daily basis as well (All of our 
products support C++ and C#).
I have made some attempts in the past to support Lazarus, and offer our 
products for it, but due to vast number of bugs and limitations in it, I have 
all but given up.
I still hope that one day I may offer our components to the lazars/FPC 
community, but that seems to be just a fantasy :-D . I am actually dropping 
support for FPC in the latest OpenWire implementation again due to 
incompatibilities and lack of Delphi features (in this case attributes).


Attributes have been developed, but are not yet in trunk.

It is ok, I don't use Lazarus (spare a brief attempt few years ago to port 
the libraries), and I probably will never use it, especially after your 
recommendation :-) , nor will probably most of my customers, and there are 
fear number of them ;-) .


I honestly regret this.

But I seriously doubt that this has to do with missing anonymous functions in 
a delphi-compatible form.


I also doubt that adding anonymous functions would make you change your mind.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread waldo kitty

It is as I thought about closures before. But this is useless without capturing
of variables by value. During creation of anonymous method you *can not bind any
values* to it. Anonymous method have only references to captured variables.
Pascal don't allows to create static variables inside function like in c-like
languages. So you also not able to create unique static variable which available
only to one instance of same anonymous method. Even if implementation will
create many separate objects for one anonymous function then all instances will
be equivalent. Because all instances will refer to same data.


i'm trying to understand what you mean by

> Pascal don't allows to create static variables inside function like in c-like
> languages.

i've done something that i think is what you speak of but it was in Borland's 
Turbo Pascal... at least TP6... i don't remember how we did it though and can't 
find any sample code in my library :(


what happened is that the value did not get cleared between invocations of the 
routine and subsequent executions could use the value already stored... this 
breaks, of course, if the memory area for the routine is cleared first...


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Boian Mitov

   Hi Michael,

Thank you!
I actually have more experience in C++ than in Delphi. I have been using 
Delphi only for ~15 years, where my active C++ experience dates back to 
1990, and I actively develop in C++ and C# on daily basis as well (All of 
our products support C++ and C#).
I have made some attempts in the past to support Lazarus, and offer our 
products for it, but due to vast number of bugs and limitations in it, I 
have all but given up.
I still hope that one day I may offer our components to the lazars/FPC 
community, but that seems to be just a fantasy :-D . I am actually dropping 
support for FPC in the latest OpenWire implementation again due to 
incompatibilities and lack of Delphi features (in this case attributes).
It is ok, I don't use Lazarus (spare a brief attempt few years ago to port 
the libraries), and I probably will never use it, especially after your 
recommendation :-) , nor will probably most of my customers, and there are 
fear number of them ;-) .
I have recently started to remove the {$IFDEF FPC} parts from the source 
code, since the chance to port to FPC seems less and less possible.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Michael Van Canneyt

Sent: Monday, March 04, 2013 9:11 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

If you want to drop FPC for because it forces you to move a line and
have to type a name in front of it, then yes, I think you are not on your
place working with pascal. 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Boian Mitov

 No need Michael,

Thank you :-) .
I am actually a master in it, as you can probably guess from our products 
:-D .
Indeed this new language is a "witchcraft", since it will not even have 
classes, structures, or even statements :-D .
It is a totally new concept ;-) . But it will take few years to develop. I 
have hired couple of developers to do some of the initial work. We will see 
how it will go ;-) .


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Michael Van Canneyt

Sent: Monday, March 04, 2013 9:19 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

There is a course in witchcraft here in the neighbourhood,
shall I send you the details so you can inscribe ?
Sounds like just the thing :-)


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Michael Van Canneyt



On Mon, 4 Mar 2013, Boian Mitov wrote:

Actually you are right indeed. I would spill a secret now. I have actually 
been working on a new language for a while, although it indeed will not only 
have anonymous methods, but will not have methods altogether, since it is a 
non procedural and non functional language, and can't even be called 
"programming" language, but that is a different story ;-) . I am really bound 
of the limitations of the existing languages, and need to find a drastic 
solution to progress further ;-) .


There is a course in witchcraft here in the neighbourhood, 
shall I send you the details so you can inscribe ? 
Sounds like just the thing :-)



Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Michael Van Canneyt



On Mon, 4 Mar 2013, Boian Mitov wrote:

I actually somewhat agree with that, except it is less readable since you 
can't follow the code flow in place but have to scroll up to see what will 
happen (in for each as example.)


If you do proper top-down programming, usually there is no need to go and look.

If I see

if F.NeedUnitTest then
  CreatePropertyUnitTest(Strings,CN,F);

then I know what CreatePropertyUnitTest does, I can follow the logic.
Most of the time, I do not need to know the details.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Boian Mitov
Actually you are right indeed. I would spill a secret now. I have actually 
been working on a new language for a while, although it indeed will not only 
have anonymous methods, but will not have methods altogether, since it is a 
non procedural and non functional language, and can't even be called 
"programming" language, but that is a different story ;-) . I am really 
bound of the limitations of the existing languages, and need to find a 
drastic solution to progress further ;-) .


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Michael Van Canneyt

Sent: Monday, March 04, 2013 4:23 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

People who want that should not be using Pascal to begin with.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Boian Mitov
I actually somewhat agree with that, except it is less readable since you 
can't follow the code flow in place but have to scroll up to see what will 
happen (in for each as example.)

Other than being more difficult to read it is otherwise the same.
If you can also pass pointers to it that exist after the function is exited, 
then it is virtually equivalent.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Michael Van Canneyt

Sent: Monday, March 04, 2013 9:03 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods



On Mon, 4 Mar 2013, Boian Mitov wrote:

This is not correct.

For anonymous functions you do not need to declare a new class.
Just name a local method.
That means move a line, and put a name in front of it. No more, no less.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Michael Van Canneyt



On Mon, 4 Mar 2013, Boian Mitov wrote:


Thank you Michael,

This is a good advise :-) .
I guess I really should stop using Delphi in the future :-) .
I am surely not using FPC and staying with Delphi for now, but I appreciate 
your advise.

Having less people use the language is the way to go :-D .


If you want to drop FPC for because it forces you to move a line and
have to type a name in front of it, then yes, I think you are not on your 
place working with pascal.


You should then move to C or Javascript, it will dramatically improve 
the number of characters you must type.


No one argues about the concept of closure.

We do not want you to have to declare N classes and M methods to be able to use 
it.

We do argue about how this can be implemented in a way that has some regard for 
the
fundamentals of pascal: verbosity, and the requirement to declare everything before 
you use it.


A local nested, named procedure has been part of Pascal since very long time.
The proposal just enhances that idea.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Michael Van Canneyt



On Mon, 4 Mar 2013, Boian Mitov wrote:


Ye, by writing 20 times more code for the same.
What here I can do with 3 lines, otherwise needs declaration of a new class, 
new interface and new instance of the class.

So what I can do here i 15 seconds would take me 1 hour to do traditionally.


This is not correct.

For anonymous functions you do not need to declare a new class. 
Just name a local method.

That means move a line, and put a name in front of it. No more, no less.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Boian Mitov

Thank you Michael,

This is a good advise :-) .
I guess I really should stop using Delphi in the future :-) .
I am surely not using FPC and staying with Delphi for now, but I appreciate 
your advise.

Having less people use the language is the way to go :-D .

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Michael Van Canneyt

Sent: Monday, March 04, 2013 4:23 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods


IMHO this is a pefectly acceptable solution.
Adds only a modifier (modifiers are not keywords) and offers all advantages 
of closures.


No need for 'anonymous' procedures, which are very unpascal-ish.
People who want that should not be using Pascal to begin with.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Boian Mitov

Ye, by writing 20 times more code for the same.
What here I can do with 3 lines, otherwise needs declaration of a new class, 
new interface and new instance of the class.

So what I can do here i 15 seconds would take me 1 hour to do traditionally.

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Martin

Sent: Monday, March 04, 2013 3:35 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

On 04/03/2013 06:06, Boian Mitov wrote:

All fine and good. But all that can be done with a *named* closure too
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel 


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin

On 04/03/2013 16:05, Alexander Klenin wrote:

Both "lambda" and "as" keywords are quite debatable, of course.



IMHO the existing procedure/function keywords should be kept. But with 
the requirement of using a defined type


Foo(  function as TVisitor; Result := x+5 end; );

or
Foo(  function as TVisitor; begin Result := x+5 end; );
Foo(  function of TVisitor; begin Result := x+5 end; );

or even
Foo(  function TVisitor( Result := x+5 ));


or anything alike
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin

On 04/03/2013 16:05, Alexander Klenin wrote:

Anonymous functions (with good syntax, of course) fall in this category.
The world recognized that fact -- rather slowly, to be sure, but
remember that "while"s and "for"s
also took decades to be accepted as standard constructs.
 I am not going to ask for proof of this statement (as for example in 
quotation of literature on the topic).

For the arguments sake, let's assume the above.


No, my proposal (which was made in the previous thread in this topic)
is following (all-caps denotes non-terminal):
1.1) A function of the form
   function NAME(PARAMS): RETURNTYPE; begin Result := EXPRESSION; end;
can be shortened to
   function NAME(PARAMS): RETURNTYPE as EXPRESSION
IMHO that is not a good idea. It adds an additional construct, that 
every reader must know how to read. It does not add/save enough to be 
needed.



If you look for the most natural, pascal like (ignoring the part that
declaring a function inline, IMHO is not that)

   ATree.VisitPreorder(TVisitor(Result := X + 5);
   ATree.VisitPreorder(TVisitor(begin Result := X + 5; end);

You are type casting the code, into a procedure of the given type.

There is certainly a merit in that, but it violates another Pascal
"basic principle" -- "prefer keywords to symbols".
We could also use the new, have a constructor for everything 
(TArray.Create) style. Personally, the idea appals me, but

   TVisitor.Create(Result := x + 5)

Another way to avoid the "as"
  lambda(TVisitor)  end

lambda acts as "begin" to the block, so there always must be an end.


Also, note that you can not omit Result assignment,
since ATree.VisitPreorder(TVisitor(X + 5)); is syntactically ambiguous.
So it becomes
ATree.VisitPreorder(TVisitor(Result := X + 5));
vs
ATree.VisitPreorder(lambda TVisitor as X + 5);

See above. The omission "of Result :=" is IMHO not desirable.


Finally, I disagree with unbalanced parenthesis -- but that's probably a typo?



yes
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Sven Barth

Am 04.03.2013 16:13, schrieb Alexander Klenin:

On Tue, Mar 5, 2013 at 1:49 AM, Sven Barth  wrote:

The use of "as" is based on an idea of mine. C# for example has "=>" and

Oxygene has "->" which I didn't consider much Pascal like. Also the compiler
needs to know the type of the lambda so it can correctly typecheck its code
(after all we have no type inference (yet :P )). So "lambda PROCVARTYPE as
EXPR/STMT" came as the most "natural" and Pascal like variant.

Alternatively, we can consider to use "is" -- it even has precedent in Ada:
http://en.wikipedia.org/wiki/Ada_(programming_language)#.22Hello.2C_world.21.22_in_Ada

Would indeed be a nice idea as well :)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Alexander Klenin
On Tue, Mar 5, 2013 at 2:10 AM, Martin  wrote:
>
> First: Stressing out: I don't like it. But if we must have one, the lambda
> approach is the best one yet.
> Reason: At least the type is declared at a pascal-like location.

I certainly agree that it is subjective in the sense that some persons
do like it, and other do not.
However my argument is that is an essential language construct, similar to
"for" loop, for example.
It is certainly possible to dislike "for" loops, and always use "while" instead.
There is even a programming language which explicitly lacks "for"
based on that reasoning.
Nevertheless, most programmers use "for" loops, because the value of
"syntax sugar" added by it
is enough to out-weight the burden of learning and understanding one
more language construct.
Anonymous functions (with good syntax, of course) fall in this category.
The world recognized that fact -- rather slowly, to be sure, but
remember that "while"s and "for"s
also took decades to be accepted as standard constructs.

> I did not note at first, but the al leaves  the "Result" away. So X+5 now
> looks like a statement.
> What would happen with
>   ATree.VisitPreorder(lambda TVisitor as begin X := min(10,x); X + 5; end);
> Reminds me of perl: the last value is the return value.

No, my proposal (which was made in the previous thread in this topic)
is following (all-caps denotes non-terminal):
1.1) A function of the form
  function NAME(PARAMS): RETURNTYPE; begin Result := EXPRESSION; end;
can be shortened to
  function NAME(PARAMS): RETURNTYPE as EXPRESSION
1.2) A procedure of the form
  procedure NAME(PARAMS); begin STATEMENT; end;
can be shortened to
  procedure NAME(PARAMS) as STATEMENT
1.3) All other cases (i.e. with several statements in the body) must
be spelled in full.
2.1) Given types
  TFuncType = function (PARAMS): RETURNTYPE;
  TProcType = procedure (PARAMS);
2.2) the function declaration
  function NAME(PARAMS): RETURNTYPE;
can be shortened to
  lambda NAME: TFuncType;
2.3) the anonymous function declaration
  function (PARAMS): RETURNTYPE;
can be shortened to
  lambda TFuncType;
2.4) Similarly, for procedures:
  lambda NAME: TProcType;
  lambda TProcType;

So, the answer to your question will be:
ATree.VisitPreorder(lambda TVisitor; begin
  X := min(10,x);
  Result := X + 5;
end);

Note that both proposals are totally orthogonal both to each other and
to anonymous functions,
and are useful in isolation -- in particular, "lambda" proposal helps
with event handlers:
1) It explicitly declares that a given procedure is supposed to be
assigned to an event of certain type,
  thus increasing readability.
2) It shortens code, especially for a case of many parameters.
3) It allows to add new parameters to event handlers without breaking user code,
  thus reducing the likehood of ugly solutions like "OnDrawCellEx".

Both "lambda" and "as" keywords are quite debatable, of course.

> If you look for the most natural, pascal like (ignoring the part that
> declaring a function inline, IMHO is not that)
>
>   ATree.VisitPreorder(TVisitor(Result := X + 5);
>   ATree.VisitPreorder(TVisitor(begin Result := X + 5; end);
>
> You are type casting the code, into a procedure of the given type.
There is certainly a merit in that, but it violates another Pascal
"basic principle" -- "prefer keywords to symbols".
Also, note that you can not omit Result assignment,
since ATree.VisitPreorder(TVisitor(X + 5)); is syntactically ambiguous.
So it becomes
ATree.VisitPreorder(TVisitor(Result := X + 5));
vs
ATree.VisitPreorder(lambda TVisitor as X + 5);

Finally, I disagree with unbalanced parenthesis -- but that's probably a typo?

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


  1   2   >