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

[Jonas Maebe]

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.


Jonas