p5pRT
commented
6 years ago From zefram@fysh.org
Created by zefram@fysh.org
When we first implemented signatures\, the requirement that they involve no vapourware meant that they had to perform only copying of arguments\, not aliasing. Since then\, aliasing has been added to the language\, albeit only experimentally so far. It would be good for signatures to have the option to alias arguments. They should continue to default to copying\, to avoid surprising the programmer with the more unusual aliasing behaviour. Aliasing should be determined separately for each parameter.
While scalar parameters can be aliased directly to argument scalars\, there is no equivalent operation that would alias an array or hash parameter. There is no array or hash object to alias\, only a list of scalars. However\, an array or hash parameter corresponding to a sequence of arguments *can* involve aliasing: an array's elements can be aliased to argument scalars\, and a hash's values (but not keys) can be aliased to argument scalars.
Another operation that is meaningful and might be included here is aliasing a parameter variable to the referent of a reference argument. There is synergy here with prototypes such as (\@)\, which encourage the passing of references.
An obvious approach to both kinds of aliasing is to incorporate the reference operator "\" into signatures. This can imitate to some extent the refaliasing syntax\, and careful placement of the "\" can help the programmer to think about which reference quantities are being equated\, to minimise confusion.
An obvious syntax to start with is "(\$x)"\, but we must be careful about which operation it shoud refer to. Considering arrays and hashes\, the matching syntax "(\@x)" clearly refers to aliasing the entire array variable (and likewise for hashes)\, so could only mean that that signature item takes a single argument\, which must be an array reference\, and the array parameter variable is aliased to the referent of the argument. For consistency\, then\, "(\$x)" must alias $x to the referent of a scalar ref argument. So (ignoring the issue of experiment warnings and the wording of argument count diagnostics)
use feature "signatures"; sub clear_referent (\$x) { $x = undef; }
would behave as
sub clear_referent { die unless @_ == 1; { use feature "refaliasing"; \(my $x) = $_[0]; } $x = undef; }
A runtime error should occur if the argument supplied for this kind of parameter is not the expected kind of reference.
If this kind of reference argument is optional\, aliasing can still be done\, but then the default value expression should be providing a default *reference* value\, with the parameter variable aliasing to the referent. That is\, the default value expression provides a default argument value\, as it does for ordinary optional parameters. For example\, in "(\@x = [])" @x would by default be an empty array. "(\@x = (3))" would cause a runtime error in the default case\, because 3 is not a reference. Note that it is meaningful for a "\@x" array or "\%x" hash parameter to have a default value\, because it corresponds to exactly one scalar argument\, whereas it is not meaningful to have a default value for a regular "@x" or "%x" that would correspond to a sequence of arguments.
If this kind of parameter is unnamed\, the argument type check should still apply. So "(\@)" will check that the argument is an array ref\, and signal an error if it is not\, but will throw away the argument if it is of the correct kind. "(\@ = ...)" should still evaluate the expression in the default case\, and error if the value is not an array reference\, but should otherwise throw the value away. "(\@ =)" should be legal just as "($ =)" is: it should perform the reference type check on a supplied argument\, and should do nothing (with no error) for an omitted argument.
Now\, aliasing to the argument scalars themselves. In terms of refaliasing syntax\, the operation for a scalar parameter corresponds to putting a reference operator on both sides of the notional assignment operator. There is no equivalent for arrays aliasing their elements or hashes aliasing their values\, and since we don't actually have an assignment operator in the signature in the usual case we can't so easily place the reference operator to imitate aliasing assignment. I suggest instead postfixing the "\" to the parameter name\, hinting at a notional "\=" aliasing operator. So (ignoring the issue of experiment warnings and the wording of argument count diagnostics)
use feature "signatures"; sub clear ($x\) { $x = undef; }
would behave as
sub clear { die unless @_ == 1; { use feature "refaliasing"; \(my $x) = \$_[0]; } $x = undef; }
With array and hash parameters we'd have "(@x\)" aliasing array elements and "(%x\)" aliasing hash values.
If an argument is optional\, following the logic of the notional "\=" operator\, the default expression still provides a default argument\, but now it's not just a default value\, it's a default *lvalue*\, which will be referenced. For example\, in "($x \= 3)" $x would by default have a value of 3\, and would be unwritable\, being an alias to the read-only 3. It's not meaningful to have an array or hash parameter that does this kind of aliasing be optional: there's nothing defective about having zero arguments to put into an array or hash.
This kind of aliasing is mostly a no-op on unnamed parameters. "($\)" should behave the same as "($)"\, and "(@\)" the same as "(@)". "($ \= ...)" should still evaluate the expression in the default case\, for side effects\, just as "($ = ...)" does. "($ \=)" should be legal just as "($ =)" is\, producing no error in the default case.
It's also necessary to think about how aliasing would interact with smartmatch type constraints\, or any other kind of type constraints that get added to the signature language.
Migrated from rt.perl.org#132472 (status was 'open')
Searchable as RT132472$