ralph wrote:
If the syntax for passing "it" to a sub
remains as verbose as it currently is,
you are probably right that "it" won't
be used to achieve brevity!
You're confusing brevity of declaration with brevity of use.
Declarations should always be relatively verbose.
Why do you think your estimate of Perl 6
usage of "it" is so much lower than is
true for the standard Perl 5 functions?
Because I don't believe many people write subroutines that
default to $_ or that rely on some particular value of $_.
In Perl 5, relying on $_ is fraught with peril, since its
global nature means you have to be wary of what happens to
it in any nested calls as well.
We ought not make that peril any easier to fall into in
Perl 6. Making $_ lexical goes a long way towards that.
Making (limited) circumvention of that lexicality depend on
a verbose and explicit syntax will help too.
Btw, can I just confirm that one can't do:
sub f ($a = <mumble>) { ... }
or
sub f (;$_ = <mumble>) { ... }
where <mumble> is the upscope it and $_
is the sub's topic.
I seriously doubt it but, as always, that's up to Larry.
If it were allowed, the syntaxes might be something like:
sub f ($a = $CALLER::_) { ... }
sub f (;$_ = $CALLER::_) { ... }
Naturally, I see this as another symptom
of the way upscope "it" is being treated
as a second class citizen,
No. It's just not being treated as a parameter.
Because it isn't one.
and that this is leading things in the wrong direction.
Actually, I'm very happy with the direction it's being led.
Besides, what's wrong with:
$foo = sub { print $_ } is given($_);
Compared with
$foo = sub { print $^_ };
The answer is brevity, or lack thereof.
But, even if $^_ *were* synonymous with $_, it
still wouldn't do what you want. The placeholder
in:
$foo = sub { print $^_ };
makes the closure equivalent to:
$foo = sub ($_) { print $_ };
which expects the topic to be passed as the argument of the
subroutine, *not* "inherited" out-of-band from the caller's
scope.
If you're proposing that there be some special exemption for
$^_ so that it (a) doesn't placehold a parameter and (b)
aliases the caller's topic instead, then I'm vehemently opposed,
since it makes $^_ a kind of *anti*-placeholder.
Introducing that kind of inconsistency would be playing straight
into Simon's hands! ;-)
Why bother with currying?
You mean placeholders. Currying is something else entirely.
Why bother with the "it" concept? None of these are necessary.
They simplify code generation, but their more
general feature is enabling brevity.
Of usage, yes, but not necessarily of declaration.
Damian
