[fpc-devel] Local procedures as procedural parameter
drdiettrich at compuserve.de
Mon Mar 14 23:30:13 CET 2005
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
> 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
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 =
IMO such a definition would better implement the strict Pascal typing,
instead of only a type equivalence determined by the procedure
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?
More information about the fpc-devel