Re: coderefs and (&) prototypes

OK now that I can read my own question, the answer seems clear ...

the parser can't decide at compile-time if a scalar like $a holds a coderef, but doing the idempotent operation \& (that means reference of the dereference) makes it undoubtable for the parser.

UPDATE:

prototypes are a compile-time not run-time issue, which explains the confusion.

@JadeNB: defining your own prototype opens the oportunity to say sub f([&$]) { ... } such that at compiletime any scalar is acceptable, which can be assured at runtime to be a coderef!¹

Cheers Rolf

UPDATE:

(1) Unfortunately this is wrong, there is no sub f([&$]) { ... } for an alternative first argument type, only sub f(\[&$]) { ... }. But this will NOT work like map() or grep(), because now the argument "absolutely must start with that character" (here & or $)

Comment on Re: coderefs and (&) prototypes Select or Download Code

Replies are listed 'Best First'.
Re^2: coderefs and (&) prototypes by JadeNB (Chaplain) on Jul 27, 2009 at 22:41 UTC
LanX suggested moving the CB discussion to a more persistent medium, so here we are. My objection to the above answer (at which the @-response was directed) was that writing `\&$a` no more guarantees that `$a` is a coderef than just writing `$a` does. (It maybe indicates more strongly that we think that `$a` is a coderef, but, if our thoughts about programs were always correct, then we wouldn't need compile-, or even run-, time checking.) We still get a run-time error if `$a` is not a coderef. Defining one's own prototype is a great solution, I agree, but doesn't help if (somewhat ironically) I'm trying to use `Scalar::Util::set_prototype` to set the prototype of a named coderef. :-)	[reply] [d/l] [select]
Re^3: coderefs and (&) prototypes by LanX (Saint) on Jul 27, 2009 at 22:50 UTC
My objection to the above answer (to which the @-response above is directed) is that writing \&$a no more guarantees that $a is a coderef than just writing $a does. Well you're right but from the perspective of the prototyped function it's clearly the goal to get a coderef at that point and nothing else. It delegates the problem to the code-dereferencing in `&$a`. so it's not anymore a problem of the implementation of prototypes but of the implementation of &-dereferencing. And you will agree that it doesn't make sense in a loosely typed language like perl to guarantee that the scalar following & is a coderef! Otherwise it would become in consequence necessarily a typed language! Cheers Rolf UPDATE: To make it clearer "prototyping" is an option to make perl-functions more "strongly typed", and the function assures this "typing" within it's possibilities, it can't look ahead and alter the behaviour of &. And & can't be strongly typed! Hence you see problems only at run-time...	[reply] [d/l]