[fpc-devel] Local procedures as procedural parameter

[DrDiettrich]

Michael Van Canneyt wrote:

> 1. What happens if f would use a variable from somefun, and f is called
>     when somefun is no longer executed ?

This can not happen when the function parameter cannot be stored
anywhere.

> 2. I see no difference whatsoever between typ_fun and iso_fun, except
>     the use of an extra type, which, in my opinion, does not change
>     anything to the usage or code of these functions. If one is allowed,
>     the other should be allowed as well.

As I understand the ISO convention, it just shall disallow to create
variables of the procedural type, which were required to store such a
reference. In Pascal two type declarations are different, even if they
look the same.


Let me add some more thoughts about procedural types:

- I like the ability to declare procedural types, the ISO convention
looks like one of the many incredible C hacks to me :-(

- For the restricted use of local subroutines as procedural parameters I
could imagine a "const" prefix in the accepting procedure declaration:

procedure my_fun(const pf: tfun);

The "const" prefix here means that the procedure pf only can be called,
but cannot be stored in a variable. The compiler then can assure that
local subroutines are passed only as const arguments. This syntax
requires no changes to the parser. The compiler message for a missing
"const" could be a warning instead of an error, to prevent
compatibility/portability problems. Other compilers should ignore the
"const", so that accordingly modified source code still should be
portable?

Hmm, the hidden frame parameter still will make a difference with local
subroutines. At least in Pascal calling convention, where the arguments
are popped by the called subroutine, not by the caller...


- I'd appreciate to define procedures based on procedural types as well.
Currently a change to the procedural type requires updates of all
derived procedure declarations. Something like:

myproc: tfun =
begin
  blabla
end;

IMO such a definition would better implement the strict Pascal typing,
instead of only a type equivalence determined by the procedure
signature.

Unfortunately(?) this syntax is incompatible with procedural variables,
so that it would disallow to create such variables. A "procedure" prefix
would make the definition look like a function returning an TProcType.
But perhaps somebody has a better idea?

DoDi