Allison Randal writes:
: Of course, this idea may have already been considered and rejected, in
: which case I'm just curious to learn the reasons.
It's been thought about, but neither accepted nor rejected yet. It's
one of those things that depends on future decisions. Certainly Hugo
and Dan will vouch for the fact that I was ruminating about similar
issues last Wednesday, though in this case I was thinking about how a
topic could supply a default to identical parameters of different
subroutine or method calls, and not just as the object of the call.
So assuming that all objects have a C<print> method that takes a
C<$handle> as an argument, you might could say
given $*OUT -> $handle {
$str.print; # same as $str.print(handle => $*OUT)
$num.print; # same as $num.print(handle => $*OUT)
$obj.print; # same as $obj.print(handle => $*OUT)
}
But that might be a bit dangerous in the general case. I think we need
a property:
my $handle is assumed
or some such.
: What would be the cost (performance, design or dwim) of making all the
: defaulting constructs pay attention to the current topicalizer in
: preference to $_?
No cost to performance, possible cost to design, cost to dwimmery
depends on the wim of the day.
There might also be a cultural price. That would be difficult to judge
in advance. (Though, of course, that's what I'm getting paid for...)
: C<when> is beautifully dwim, testing against the topicalized value (the
: given) when there is one and $_ when there isn't. It seems like it might
: be useful if C<print>, C<chomp>, C<s///>, etc. behaved the same way.
:
: given $foo -> $bar {
: when /something/ { # matches against $bar
: chomp; # also on $bar
: s/this/that/; # also on $bar
: print; # prints $bar
: }
: }
:
: I like the idea of being able to say "defaulting constructs always obey
: the lexical scope of topicalizers".
Of course, the waterbed theory of linguistic complexity says that if
you push the complexity down one place, it comes up somewhere else. In
this case, $_ would no longer have the meaning of "the default variable",
but the more tenuous meaning of "the default default variable".
: For the most part, the change would have no impact on current code.
: Examples that use $_ would still behave the same, as $_ is the
: topicalized value anyway:
:
: for @foo {
: s/this/that/; # substitute on $_
: ...
: }
:
: Examples that use an aliased named variable would also work as-is, they
: would merely have the option of simplifying:
:
: for @foo -> $bar {
: # $bar =~ s/this/that/; # still works
: # print $bar;
:
: s/this/that/; # would do the same thing
: print;
: ...
: }
But if we have a Perl 5 snippet that says:
for $bar (@foo) {
s/this/that/;
print;
}
we'd have to translate to:
for @foo -> $bar {
$_ =~ s/this/that/;
print $_;
}
since in Perl 5 that aliased C<for> wouldn't clobber the outer $_.
Certainly it's doable, if distasteful.
: There are problems with embedded topicalizers. Someone might
: intentionally use the fact that the $_ of the outer topicalizer is not
: clobbered by the aliased named variable of the inner topicalizer
: ($nonsense), and use a defaulting construct on $_ within the embedded
: scope.
:
: for @foo {
: s/this/that/; # on $_
: for @stuff -> $nonsense {
: s/that/another/; # currently on $_,
: # on $nonsense with change
: ...
: }
: }
:
: Since it can be done, I'm sure the Perl 5 counterpart of this exists in
: some code somewhere. And even if $_ is officially "just another lexical"
: it still seems uncomfortable to have to code:
: $_ =~ s/that/another/;
Yes, but...
: This may be a tolerable discomfort. I'm not sure. Using a second aliased
: named variable would also work, and has the advantage of making it more
: obvious (to the human eye) exactly which variable was matched against,
: especially within numerous levels of embedded topicalizers.
:
: for @foo -> $bar is rw {
: for @stuff -> $nonsense {
: $bar =~ s/that/another/;
: ...
: }
: }
This is precisely how we manage it in natural language. When there get
to be too many possible "its", we resort to explicit naming, or some
sort of positional tagging ("the former or the latter", "this or
that"). We could go as far as to outlaw an outer $_ within nested
topicalizers, but that's likely a bit too heavy-handed.
: If you wanted to set up a context in which a particular value was the
: default, instead of assigning the value to $_, you could wrap the code
: in a C<given>.
:
: # Actually, this should already work, because $_ is
: # aliased to the value of $foo.
: given $foo {
: chomp; # on $_
: s/this/that/;
: print;
: }
:
: # This would have the same effect.
: given $foo -> $bar is rw {
: chomp; # on $bar
: s/this/that/;
: print;
: }
:
: Is it an abuse of C<given> to use its abilities as a topicalizer outside
: the context of a switch statement? Well, possibly, but an interesting
: one. :)
Well, the default binding to $_ was meant to allow topicalizers to be
abused in just that fashion. It's only when we start nesting them that
we run into problems, I think.
: Simply pondering,
No need to be tentative, though I appreciate a good will behind it.
But don't worry, I'm not feeling threatened just because there's a real
linguist on the premises.
Well, not much... :-)
Larry
