Re: Topicalizers: Why does when's EXPR pay attention to topicaliz er r egardless of associated variable?

[Larry Wall]

Allison Randal writes:
: On Thu, Feb 28, 2002 at 03:17:19PM -0600, Garrett Goebel wrote:
: > I do worry that as Perl grows richer, so does the need for underlying
: > consistency and simplicity. 
: 
: You're not alone in that.
: 
: > I guess it is all about seeking the correct balance. And that is
: > something Larry and the Perl community have a pretty good track record
: > with so far.
: 
: As Damian is so fond of saying, "Trust Larry".

Heh.  Well.  Maybe that works because I don't entirely trust myself.

I should update y'all to my current thinking, which is that $_ is
always identical to the current topic, even if the topic is aliased to
some other variable.  To get at an outer topic, you'd have to use the
same mechanism we'll use for redeclared lexicals:

my $foo = $OUTER::foo;

for @x {# aliases $_
for @y -> $y {  # aliases both $x and $_
print $OUTER::_;
}
}

I think this will encourage people not to use $_ for outer loops, which
is a confusing practice.  Use of $_ should generally be reserved for
inner loops.

I expect some people will want a stricture that says you can't use $_
in a lexical scope that aliases the current topic to some other variable.
That is, it would be illegal to say

for @x {# aliases $_
for @y -> $y {  # aliases both $x and $_
print $_;   # but this is forbidden
}
}

The $_ variable would still be there for operators that want to know
the current topic without knowing its variable name, but you'd have to
refer to it as $y in your program.  Or if you really meant the outer $_,
use $OUTER::_.

I like the simplicity of defining $_ as the current topic, period.  If
there's more than one topic, you should really be using explicit
variable names for clarity.  That's how we do it in natural languages.
We stop talking about "it", and start talking about "this" and "that",
or "A" and "B".

Admittedly, OUTER is kind of klunky, especially if you want to say
$OUTER::OUTER::_.   This klunkiness could be construed as a feature.
Doubtless someone will suggest replacing OUTER:: with a secondary sigil
such as "<" so that you can say something like $<<_ instead.  I'm not
sure that would be an improvement from a readability point of view.
The hiding of outer variable names is not something we want to
encourage in general.

For it, that's now.

Larry

Re: Greetings

[Larry Wall]

Luke Palmer writes:
: Hello everyone.
: 
: I just subscribed to this list. My name's Luke and I'm a perl
: devotee. And I'm starting out with a bang. Here goes:
: 
: I have just read through exegesis 3, and I found the bit about
: defining your own new operators (eg. operator:*#@&) to be a little
: strange. Not confusing, but esoteric and random. What functionality
: does this provide to the language other than "It's cool."

In evolutionary terms, the ability to be more adaptive.

: I think, if anything, it would make things more confusing. Suppose a
: module that implemented, say, a vector (disregarding that this isn't
: really needed) provided a new operator .prod for dot product. What
: would happen in the following case:
: 
:   use Vector;
:   $v = new Vector;
:   $v.prod $j;
: 
: Does that last statement mean $v.prod($j), or ($v) .prod ($j)? Not to
: mention, how is the user supposed to know that she can't say
: $v.prod($j)?

Doubtless such a token would be frowned upon.  Good reason to use a
Unicode character instead, to avoid conflict with builtins.  Gee, maybe
we should use U+22C5, "DOT OPERATOR".

: What about the example in the exegesis: 'operator:*#@&'? Take the
: following code:
:   
:   $f *#@&
:$g;
: 
: What does this mean? Does this mean $f * $g with #@& as a comment, or
: does it mean $f *#@& $g?

The longest-token rule means it would be interpreted as the latter.
We already have tokens that contain # and are not interpreted as
comments, things like $#foo and s#foo#bar#;

: But anyway, those are just language semantics
: that could be worked out one way or another. The big confusion lies in
: documentation and memory (human memory, that is). When your reading
: through documentation for this Vector class, which would you rather
: see?
: 
:   Vector provides an operator `.prod' for computing dot
:   products. It has the same precedence as the Perl binary *
:   operator. It also provides the xprod operator which has the same 
:   precedence as Perl's binary + operator.
: 
: --or--
: 
:   Vector provides two methods, dot and cross, which compute the
:   dot product and the cross product, respectively, on their
:   arguments.
: 
: The latter has significantly less to remember, using the
: ever-so-familiar method, rather than entering two new operators with
: precedences and all into your knowledge base.

Hmm, by that argument, all mathematical formulas ought to have nothing
but words in them.  But there are also a great deal of ever-so-familiar
items from math culture (well, ever-so-familiar to mathematicians), and
many of mathematicians would rather see the punctuation they're
familiar with.

: Also I think that these new operators would add a new level of
: obfuscation to the language when it's not intended to be
: obfuscated. When one encounters the *#@& operator, one must consult
: the documentation for that operator, while method names are forced (at
: least for people with any good taste) to make a small amount of sense.

And there you've put your finger on it.  Cultural tastes will have to
be enforced in either case.  I'm certainly going to quarrel with any
one who wants to overload << to be the output operator.  And Unicode
operators will be culturally unacceptable as long as it's difficult
to enter Unicode on the terminal.  But I don't expect that to remain
the case forever, and I want Perl to be a good language for 20 years
from now.

: Not to mention the extra strain on the lexer, not that it matters
: much.

If strain on the lexer were a design criterion, I blew it long ago.  :-)

: But in general, I suggest that the whole roll-your-own operator thing
: be stripped from Perl 6. Not completely, however. I like the idea of
: overloading existing operators, which has long been a part of the
: language.

That kind of limitation forces people to overload << for output.

: I also kind of like the idea of defining infix
: operators. But I think that would come back to the whole complication
: with precedences again, which I don't find much elegance in. 

I think that's a non-issue.  The definition will say, "This is to be
thought of as a kind multiplicative operator," and people will know
just how it behaves with respect to precedence.  We don't necessarily
have to grow the precedence table to deal with new operators.

: In summary, roll-your-own operators seem to be a contrived attempt at
: being revolutionary, without providing much practicality.

Depends on how you look at it.  It's more to enable something revolutionary
later that we haven't thought of yet.

: Not to bash them or anything :-P

Bash away.  It's all grist for the rock tumbler.  :-)

Larry