On Mon, Feb 25, 2002 at 10:07:12AM -0800, Larry Wall wrote:
>
> 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.
Ah! Interesting.
I can see my explanatory charts expanding... Instead of reducing the
classes of defaulting constructs down to one, we've increased it to 3:
those that default to $_ (the majority), those that default to the given
when there is one (C<when>) and those that default to the value flagged
as assumed. Hmmm... lots of interesting questions here. Like, would the
third class have a secondary default of $_ too? Can there be more than
one "assumed" value in scope? Will we be able to define our own methods
that access the "assumed" value?
I know, no answers yet. They will come in time.
> No cost to performance, possible cost to design, cost to dwimmery
> depends on the wim of the day.
dwim -> dwhim :)
> 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...)
Ah, yes, cultural change is ever so much more touchy than language
change alone.
> 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".
Indeed. And aside from weakening $_, "topic" is not nearly as simple a
concept to explain as $_. Sure $_ is strange to Perl newbies, but it's
at least a concrete variable.
> 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.
Probably. Even human languages don't put such absolute restrictions on
methods of back-reference. It's left up to the speaker to decide when
they're no longer comfortable using "its" and need a noun instead. Which
of course leads to infinite variations in style, but alot more freedom.
Hmmmm... just like Perl. :)
> 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.
Wonderful! Now, let's see what else I can go bend... ;)
> No need to be tentative, though I appreciate a good will behind it.
Why, thank you.
> But don't worry, I'm not feeling threatened just because there's a real
> linguist on the premises.
>
> Well, not much... :-)
<chuckles> Larry Wall threatened by a geekette in the sidelines? What a
silly idea! :)
Well, I'll be interested to watch how topicalizers develop in Perl 6.
It's a really useful feature in human languages, and as far as I know,
Perl is the only computer language to use it. Very exciting.
Allison
