[fpc-devel] Question about Syntax: I there a reason for this design?

[Sven Barth]

On 21.09.2014 12:13, Jonas Maebe wrote:
> On 21/09/14 08:10, Samuel Herzog wrote:
>> But it's not accepted.
>>
>> *procedure* TFormThreading.Button1Click(Sender: TObject);
>> *var*
>>   aTask: ITask;
>>
>> **    procedure* *MyTask*;
>>      *begin*
>>        *sleep (3000); // 3 seconds*
>>        *ShowMessage ('Hello');*
>>     * end*
>>
>> begin*
>>   // not a thread safe snippet
>>   aTask := TTask.Create(*MyTask*);
>>   aTask.Start;
>> *end*;
>>
>> I just wonder if there is a valuable reason to do it why my example is
>> not allowed or would it be easy to make this available in free-pascal?
>
> In a perfect world: yes, it would be easy to make this available in FPC.
>
> In the real world where people write a ton of code in assembler or use
> pointer hacks to expose low level implementation details no one should
> rely on: it would probably make a few very vocal people unhappy because
> to be able to pass nested routines to "reference to procedure/function"
> parameters, the way they access variables in the parent frame (and the
> way they receive the parent frame) needs to be changed. And hence all
> these low level hacks would break.
>
> I think that this is, possibly together with the fact that anonymous
> methods are a buzzword that you want to be able to add to your feature
> list, probably the reason Embarcadero didn't simply use nested routines
> instead of adding anonymous methods.
>
> We could of course introduce yet another calling convention modification
> for nested routines to work around this (we already have two) so that
> both the old and new behaviour can coexist. The downside is that it
> makes the compiler more complex and hence harder to modify in the future
> and/or easier to break (every such modification needs to be implemented
> for every calling convention on every platform).
>
> As you observed, anonymous methods and nested routines are essentially
> identical other than the syntax, and I agree the latter generally also
> result in better readable code.  Therefore I'm still inclined to
> implement it somehow (at least for C-blocks, as already partially
> implemented in http://svn.freepascal.org/svn/fpc/branches/blocks/),
> because it seems a shame not to use an existing, perfectly suited
> language construct and instead force everyone to use a new one.

Agreed.

Though I would also love to have real lambda expressions which would 
only use an expression, not a statement and neither a block of 
statements (though I'm still "fighting" with the syntax in my mind):

=== code begin ===

procedure FilterGreater(aSomeList: specialize TList<LongInt>; aValue: 
LongInt);
begin
   aSomeList.Filter(lambda x: LongInt as x > aValue);
end;

=== code end ===

Regards,
Sven