Just trying to summarise the want* thread so far:
sub wantwhat {
if (wantvoid()) { # possibly?
print "VOID\n";
} elsif (wantarray()) { # have this one already
qw(L I S T), "\n";
} elsif (wantstring()) { # possibly? (or wantnumeric()?)
'STRING';
} else { # must be numeric, then...
42;
}
}
wantwhat; # "VOID\n" gets printed
$a = wantwhat; # 'STRING' or 'NUMERIC' depending on the "history" of $a?
# 'STRING' by default if the $a is unseen so far?
$b += wantwhat; # $b incremented by 42
$c .= wantwhat; # $c appended by 'STRING';
print wantwhat; # "LIST\n" gets printed
@d = wantwhat; # @d becomes ('L', 'I', 'S', 'T', "\n")
++jhi;
P.S. Could wantarray() return instead of 1 (in case there is _an_
array waiting) the length() of the array waiting? If the array
is 'unbounded' (containing one or more @variables)
the "length" returned could be -1? This change would not break
the scripts testing for undefinedness, only the ones testing
explicitly for "wantarray() == 1" (which I doubt are far and few
between...). In case you worry about
() = foo(); # foo possibly returning a list
and people testing in sub foo for "wantarray ? @bar : $goo"
it seems that one cannot assign to an empty list:
Can't modify stub in list assignment at foo line 7, near ");"
Execution of foo aborted due to compilation errors.
The error message is a bit obscure (what "stub" where?)
but TFperldiag tells us:
(F) You aren't allowed to assign to the item indicated, or otherwise
try to change it, such as with an autoincrement.
Can some of you think of / find in your own scripts places where
this possible new wantarray() behaviour would break things?
Oh, why do I want such a feature? I must confess that I am not
quite decided yet :-) Still in the irresponsible Perl 6 brainstorming
mode... at least one could possibly a) make the subs behave
differently in case different numbers of "scalars" are waiting in a list
(e.g. ($fh1, $fh2) = IO::Open->new could give me a pipe
whereas $fh1 = IO::Open->new could give a "normal" open,
just to remark on one of the other open brainstorming threads :-)
(ok, that was a bad example: here our usual wantarray() would
be enough...)
b) possibly optimising the list-returning subs by instead of just
'leaking' the possibly-discarded extraneous values the subs could
see how many values they need to return
c) it _feels_ more 'orthogonal' and informative to return instead
of just a flag (is array/is not) a little bit more about the array/list
waiting in there.
End of post scriptum.
sub wantwhat {
if (wantvoid()) { # possibly?
print "VOID\n";
} elsif (wantarray()) { # have this one already
qw(L I S T), "\n";
} elsif (wantstring()) { # possibly? (or wantnumeric()?)
'STRING';
} else { # must be numeric, then...
42;
}
}
wantwhat; # "VOID\n" gets printed
$a = wantwhat; # 'STRING' or 'NUMERIC' depending on the "history" of $a?
# 'STRING' by default if the $a is unseen so far?
$b += wantwhat; # $b incremented by 42
$c .= wantwhat; # $c appended by 'STRING';
print wantwhat; # "LIST\n" gets printed
@d = wantwhat; # @d becomes ('L', 'I', 'S', 'T', "\n")
++jhi;
P.S. Could wantarray() return instead of 1 (in case there is _an_
array waiting) the length() of the array waiting? If the array
is 'unbounded' (containing one or more @variables)
the "length" returned could be -1? This change would not break
the scripts testing for undefinedness, only the ones testing
explicitly for "wantarray() == 1" (which I doubt are far and few
between...). In case you worry about
() = foo(); # foo possibly returning a list
and people testing in sub foo for "wantarray ? @bar : $goo"
it seems that one cannot assign to an empty list:
Can't modify stub in list assignment at foo line 7, near ");"
Execution of foo aborted due to compilation errors.
The error message is a bit obscure (what "stub" where?)
but TFperldiag tells us:
(F) You aren't allowed to assign to the item indicated, or otherwise
try to change it, such as with an autoincrement.
Can some of you think of / find in your own scripts places where
this possible new wantarray() behaviour would break things?
Oh, why do I want such a feature? I must confess that I am not
quite decided yet :-) Still in the irresponsible Perl 6 brainstorming
mode... at least one could possibly a) make the subs behave
differently in case different numbers of "scalars" are waiting in a list
(e.g. ($fh1, $fh2) = IO::Open->new could give me a pipe
whereas $fh1 = IO::Open->new could give a "normal" open,
just to remark on one of the other open brainstorming threads :-)
(ok, that was a bad example: here our usual wantarray() would
be enough...)
b) possibly optimising the list-returning subs by instead of just
'leaking' the possibly-discarded extraneous values the subs could
see how many values they need to return
c) it _feels_ more 'orthogonal' and informative to return instead
of just a flag (is array/is not) a little bit more about the array/list
waiting in there.
End of post scriptum.