Re: $_ defaulting for mutating ops
On Wed, 2 Nov 2005, John Williams wrote: surprises including operandless operators. Including mutating operandless operators. What is s/// after all? Or is there a good reason for an asymmetry between different classes of operators? Well, s/// is a term, for one thing. It is not so much an operator, as it is a subroutine with really strange syntax, and the side-effect of changing the $_ variable. You need to use an operator to get it to affect a different variable. While others have pointed out that this is not that much of a difference from a strictly technical pov, I'll say that this is a good point! But since I _still_ like the proposal, differently from the person who made it in the first place, maybe consistency could be re-gained allowing the smart match operator to perform esoteric forms of mutation, e.g. $var ~~ ++; # Ouch, and how 'bout $var++ instead? ;-) At least this would help in the direction of curing the fear that P6 won't be just as suited for obfuscation as P5 is... Michele -- I agree with Tore; it's sort of a Zen question. If you have to ask, it means you won't understand the answer. If you know enough to understand the answer, you won't need the question. - Joe Smith in clpmisc, Re: Perl neq Python
Re: $_ defaulting for mutating ops
On Wed, 2 Nov 2005, Rob Kinyon wrote: I think the difference comes from the Principle of Least Surprise. The various operators being discussed in this thread are all operators which are in languages that have common use - C, C++, Java, the .Net stack, etc. Regexen and the various built-ins are generally considered to be Perl-specific, so if they're weird, this is just a Perl-ism. The PoLS doesn't apply. I still don't buy the argument. At least in principle PoLS does apply for a newbie may be surprised to know that certain operators act implicitly on $_ and certain other don't. And yes: there are lots of languages having (e.g.) a ++ operator, mostly derived from C. But Perl's C++ already allows an extended syntax wrt that of those other languages, that is: I'm not really sure, but I don't think that in C you can do (the equivalent of) C($u*=5)++ - not that you need it that often, granted! But it is backwards compatible with the standard usage. Now letting aside other reasons why the proposal should not be accepted, if it where, it would not be disruptive of current behavior. You could have $_++ *and* bare ++. And newbies learn early enough that $_ is the implicit topicalizer in Perl; moreover ++ will still look intuitively enough like the incrementing op. So I think it won't be that difficult for them to understand what's going on, the biggest remaining doubt being whether it's ++$_ or $_++. But that's just, say, a clpmisc or PM post away and anyway it will be in the docs (no, I know it won't, but that's not the point...) Yes, from a consistency point of view, ALL operators should default to $_ or some other sensible item ($*STDIN for , etc). However, the PoLS does need to guide our decisions. Hmmm, it's so difficult for me to keep up with P6, but I *think* has been phased out in favour of prefix unary C=. Michele -- you look around what do you see? I'll tell you what I see is a world belonging to me - Pennywise, Living For Today.
Re: $_ defaulting for mutating ops
HaloO, Michele Dondi wrote: And yes: there are lots of languages having (e.g.) a ++ operator, mostly derived from C. But Perl's C++ already allows an extended syntax wrt that of those other languages, that is: I'm not really sure, but I don't think that in C you can do (the equivalent of) C($u*=5)++ - not that you need it that often, granted! But it is backwards compatible with the standard usage. Actually I'm not sure if Perl 6 allows ($u *= 5)++; because the return value of *= is the rvalue 5 and *not* $u as an lvalue. Correct me if I'm wrong. Otherwise how would the expanded form ($u = $u * 5)++; behave when extented by yet another assignment ($y = $u = $u * 5)++; # $y++ or $u++ and recollapsed as ($y = $u *= 5)++; say $y; # 6? Now letting aside other reasons why the proposal should not be accepted, if it where, it would not be disruptive of current behavior. I think there is a much deeper running unresolved issue in Perl 6 as of now: the underspecified execution model and how it relates to the type and OO system! I personally would like to see something akin to adjoined operators in mathematics. As in matrix multiplication where A * B * x with A and B matrizes and x a vector. The idea is that you don't start from the vector but pre-multiply A and B. That is the associativity is (A * B) * x At that stage you could drop the application to x and store the resulting action in another variable C := (A * B) for later application. Writing the above with Perl6 sigils would come out as A * B * $x; and then C = A * B; is a calculated code object just like $y = $a * $b; is a calculated value. This is what I would call first class operators! BTW, I see junctions beeing a prime example of the above. And handling them through a data (non sigiled) variable would prevent their magic to come forth unintentional. As a nice side effect the importance of the sigil would be increased. --
Re: $_ defaulting for mutating ops
$ perl -le '$u=1; ($y=$u*=5)++; print $y' 6 It's interesting to note that this parse (due to precedence) as ($y=($u*=5))++, not (($y=$u)*=5)++ This is important for overloaded operators (which are going to become much easier to do in Perl6). The importance arises if Perl6 allows assignment to be overloaded like Ruby does. If it does, then the two expressions aren't guaranteed to be identical as they are now in Perl5. Rob
Re: syntax-variants, RPN (was: Re: $_ defaulting for mutating ops)
On Wed, 2 Nov 2005, Ruud H.G. van Tol wrote: http://www.nntp.perl.org/group/perl.perl6.language/17556 I understand that Perl6 allows blocks with changed/enhanced syntax, so it is or will become possible (to add it) as if it was in the core language. Do I understand that right? Something as simple as a 'use RPN' in a block? (assuming that someone created such an RPN-pre-processor or -compiler) Indeed this is what that we all know. Of course the possibility of doing so will depend on the possiblity of building up suitable RPN syntax consistent with the rest of the syntax. Michele -- E' molto piu' facile affrontare il lutto, il disonore e la perdita della propria anima - che questo tipo di fame prolungata. - Joseph Conrad, Cuore di Tenebra.
Re: $_ defaulting for mutating ops
On Thu, 3 Nov 2005, Sam Vilain wrote: That being said, there are probably other more pressing reasons that ops should not accept $_ as default; I would guess, for a start, it makes determining semantics very difficult. Does ++; mean postfix:++ or prefix:++ ? If we had it, I think we would be more interested in it for incrementing $_ than for its return value, so it wouldn't make such a huge difference. However I find myself using $var++ much more often than ++$var, and I'm biased to think this is the general situation: if it is actually so, then the choice should fall on the former. If my impression is just a personal artifact... oh, don't mind! Michele -- Billy: I'm scared Poncho. Poncho: Bullshit! You ain't afraid of no man! Billy: There's something out there waiting for us, and it ain't no man. We're all gonna die. - Predator (1987)
Re: syntax-variants, RPN (was: Re: $_ defaulting for mutating ops)
On 11/3/05, Michele Dondi [EMAIL PROTECTED] wrote: On Wed, 2 Nov 2005, Ruud H.G. van Tol wrote: http://www.nntp.perl.org/group/perl.perl6.language/17556 I understand that Perl6 allows blocks with changed/enhanced syntax, so it is or will become possible (to add it) as if it was in the core language. Do I understand that right? Something as simple as a 'use RPN' in a block? (assuming that someone created such an RPN-pre-processor or -compiler) Indeed this is what that we all know. Of course the possibility of doing so will depend on the possiblity of building up suitable RPN syntax consistent with the rest of the syntax. If Perl6 is parseable by Perl6, then wouldn't you be able to completely throw out the default Perl6 syntax and create your own, completely unrelated syntax? I don't know ... maybe you have PGE::Ruby that would throw out the P6 grammar and give you Ruby's grammar within the block. Then, it's just a matter of describing what PGE::RPN does - what it adds, what it removes, and what it modifies. In my opinion, if you use a grammar extension, ALL bets are off within that scope until you've read the documentation. Literally anything and everything can happen, if the author deemed it so. It's a source filter-like construct that doesn't suck because source filter-like constructs are part of the spec. Rob
Re: $_ defaulting for mutating ops
On Fri, 28 Oct 2005, Ruud H.G. van Tol wrote: Or RPN-like: $x #= 2* 1+ 3/; Being a big fan of RPN myself (and considering it quite natural), I'd appreciate very much such a feature. I had asked myself about RPN features in P6, albeit in a probably unreasonable fashion: http://www.nntp.perl.org/group/perl.perl6.language/17556 Michele -- [about penis-enlargement spam] Suppose you (applies to male readers only!) had taken advantage of every offer of the above type received, and all had worked as claimed. Estimate how long it would be. - Derek Holt in sci.math (slightly edited)
Re: $_ defaulting for mutating ops
On Fri, 28 Oct 2005, John Williams wrote: But IMHO the reduction in typing for this relatively minor issue is not really worth the surprise to newbies at seeing operandless operators. I don't buy that argument as newbies are already exposed to all sorts of surprises including operandless operators. Including mutating operandless operators. What is s/// after all? Or is there a good reason for an asymmetry between different classes of operators? Michele -- = (But it is impossible to even imagine an operating-system which would = not crash before the sun has burned all of its hydrogen, let alone not = crash before the end of the universe.) I find it hard to imagine an operating system which would not crash before the end of the week - Gerry Myerson in sci.math
syntax-variants, RPN (was: Re: $_ defaulting for mutating ops)
Michele Dondi: Ruud H.G. van Tol: Or RPN-like: $x #= 2* 1+ 3/; Being a big fan of RPN myself (and considering it quite natural), I'd appreciate very much such a feature. I had asked myself about RPN features in P6, albeit in a probably unreasonable fashion: http://www.nntp.perl.org/group/perl.perl6.language/17556 I understand that Perl6 allows blocks with changed/enhanced syntax, so it is or will become possible (to add it) as if it was in the core language. Do I understand that right? Something as simple as a 'use RPN' in a block? (assuming that someone created such an RPN-pre-processor or -compiler) -- Grtz, Ruud
Re: $_ defaulting for mutating ops
On Wed, 2 Nov 2005, Michele Dondi wrote: On Fri, 28 Oct 2005, John Williams wrote: But IMHO the reduction in typing for this relatively minor issue is not really worth the surprise to newbies at seeing operandless operators. I don't buy that argument as newbies are already exposed to all sorts of surprises including operandless operators. Including mutating operandless operators. What is s/// after all? Or is there a good reason for an asymmetry between different classes of operators? Well, s/// is a term, for one thing. It is not so much an operator, as it is a subroutine with really strange syntax, and the side-effect of changing the $_ variable. You need to use an operator to get it to affect a different variable. It looks funny no matter how much you squint your eyes. Not that that is a bad thing of course, but I don't think it should be used as an example for operators to follow. ~ John Williams
Re: $_ defaulting for mutating ops
On Wed, 2005-11-02 at 11:46 -0700, John Williams wrote:
It is not so much an operator, as it is a subroutine with really strange
syntax, and the side-effect of changing the $_ variable. You need to use
an operator to get it to affect a different variable.
operators _are_ subroutines. There is no difference.
multi sub *infix:* (Set $one, Set $two) returns Set {
$one.intersection($two);
}
Sam.
Re: $_ defaulting for mutating ops
On Wed, 2005-11-02 at 09:03 -0500, Rob Kinyon wrote: I think the difference comes from the Principle of Least Surprise. The various operators being discussed in this thread are all operators which are in languages that have common use - C, C++, Java, the .Net stack, etc. Regexen and the various built-ins are generally considered to be Perl-specific, so if they're weird, this is just a Perl-ism. The PoLS doesn't apply. Yes, from a consistency point of view, ALL operators should default to $_ or some other sensible item ($*STDIN for , etc). However, the PoLS does need to guide our decisions. I think the PoLS should be applied firstmost and foremost to a person who is learning the language without any preconceptions of how previous languages work. The logical building blocks of how the language works should build on each other; the fewer exceptions relative to *those foundations* the better. Specifically, catering for the preconceptions of how the language behaves as a whole to those trained in lower order languages like you mention (though is .net a language?) should probably be avoided. That being said, there are probably other more pressing reasons that ops should not accept $_ as default; I would guess, for a start, it makes determining semantics very difficult. Does ++; mean postfix:++ or prefix:++ ? Sam.
Re: $_ defaulting for mutating ops
Sam Vilain skribis 2005-11-03 11:01 (+1300): Does ++; mean postfix:++ or prefix:++ ? I no longer think $_ defaulting for mutating ops is a good idea, but to answer your question, read the original post: all these would imply the LHS, so that makes ++ postfix. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: $_ defaulting for mutating ops
On Tue, 25 Oct 2005, Juerd wrote:
For comparison, here is the same code snippet again. First with, and
then without explicit $_.
With:
given ($subject) - $_ {
$_ ~~ s/foo/bar/;
$_++;
$_ x= 2;
$_ ~= !;
}
Without:
given ($subject) {
s/foo/bar/;
++;
x= 2;
~= !;
}
I think the latter is more elegant, without reducing legability or
maintainability. I also think that the code is immediately obvious, even
to people coming from Perl 5, who never read this thread.
I don't really agree with your method of addressing the issue. When I have
been annoyed by this issue it is because I can write $x = $x * 2 as
$x *= 2;
which is elegant, but $x = $x * 2 + 1 requires two statements when using
meta-operator-equals:
$x *= 2;
$x += 1;
which is probably less elegant than the original $x = $x ... form.
One could cascade those with extra parens...
($x *=2) += 1;
(($_ += 1) x= 2) ~= !;
If one were to change the associativity of the meta operators such that
the parens were not needed the result would be very similar to your
example, minus a few semicolons.
$_ += 1
x= 2
~= !;
however, I would definitely want someone other than myself to ponder the
implications of mucking with associativity like that.
But IMHO the reduction in typing for this relatively minor issue is not
really worth the surprise to newbies at seeing operandless operators.
~ John Williams
Re: $_ defaulting for mutating ops
But IMHO the reduction in typing for this relatively minor issue is not really worth the surprise to newbies at seeing operandless operators. AMEN! Rob
Re: $_ defaulting for mutating ops
John Williams: ($x *=2) += 1; Or ($x *= 2) ++; Maybe the comma should be taught a new trick: $x *= 2, ++, /= 3; meaning $x = (($x * 2) + 1) / 3; Or RPN-like: $x #= 2* 1+ 3/; -- Grtz, Ruud
Re: $_ defaulting for mutating ops
On 10/28/05, Ruud H.G. van Tol [EMAIL PROTECTED] wrote:
John Williams:
($x *=2) += 1;
Or ($x *= 2) ++;
Maybe the comma should be taught a new trick:
$x *= 2, ++, /= 3;
meaning
$x = (($x * 2) + 1) / 3;
Or RPN-like:
$x #= 2* 1+ 3/;
Oh, gee, why don't we just go with:
(/ 3) . (+ 1) . (* 2) $ x
Probably because it's not helping readability anymore... at all.
I do like section notation. That is, in Haskell:
map (+3) list
Is equivalent to:
map { $_ + 3 } list
However, I don't think we have any syntax left for it. Section
notation greatly improves readability in some specific cases, but it
would mean breaking out a new pair of bracketing operators, because
otherwise we get term/operator confusion (which is probably the case
for Juerd's proposal in general, too).
Because of the syntax issues, it's probably best to keep the status
quo on this one.
Luke
Re: $_ defaulting for mutating ops
On 10/25/05, Juerd [EMAIL PROTECTED] wrote:
I think it'd be great if +=, ~=, +=, ++, etc, could all assume $_ on
their LHS when there is no obvious operand.
This clashes with prefix:=, but that's nothing a space cannot fix.
Same for lvalue subs called x or xx (or X or XX).
my $subject = foo foo foo;
given ($subject) {
s/foo/bar/; # bar foo foo
++; # bar foo fop
x= 2;# bar foo fopbar foo fop
~= !; # bar foo fopbar foo fop!
}
Especially bare ++ would be useful, I think.
Did you post this specifically to anti-address the fear that P6 will
be more line-noise-ish than P5? :-p
Rob
Re: $_ defaulting for mutating ops
Rob Kinyon skribis 2005-10-25 8:37 (-0400):
Did you post this specifically to anti-address the fear that P6 will
be more line-noise-ish than P5? :-p
No. Leaving out $_ is one of the important features in *reducing* line
noise. We're all very used to seeing it, but to most people it is just
two more non-alphanumeric characters.
Reducing line noise isn't my goal, though. I feel that the implicit
defaulting to $_ makes Perl a more natural and elegant language, and
would like this principle being extended to these operators.
For comparison, here is the same code snippet again. First with, and
then without explicit $_.
With:
given ($subject) - $_ {
$_ ~~ s/foo/bar/;
$_++;
$_ x= 2;
$_ ~= !;
}
Without:
given ($subject) {
s/foo/bar/;
++;
x= 2;
~= !;
}
I think the latter is more elegant, without reducing legability or
maintainability. I also think that the code is immediately obvious, even
to people coming from Perl 5, who never read this thread.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: $_ defaulting for mutating ops
On Tue, 25 Oct 2005, Rob Kinyon wrote:
On 10/25/05, Juerd [EMAIL PROTECTED] wrote:
I think it'd be great if +=, ~=, +=, ++, etc, could all assume $_ on
their LHS when there is no obvious operand.
[snip]
Especially bare ++ would be useful, I think.
Did you post this specifically to anti-address the fear that P6 will
be more line-noise-ish than P5? :-p
No, to address the fear that P6 won't be just as suitable for
{obfuscation,golfing} as P5 is and that it would spoil those cultures.
Incidentally I think it'd be great too.
Michele
--
Free software, not just Linux, is a major problem for Microsoft.
It's a big mistake thinking they don't understand free software, or its mechanics.
They understand it all too well, and they don't like it - not one little bit!
- Eddy Macnaghten
Pronouns [Re: $_ defaulting for mutating ops]
On Tue, 25 Oct 2005, Juerd wrote:
Reducing line noise isn't my goal, though. I feel that the implicit
defaulting to $_ makes Perl a more natural and elegant language, and
would like this principle being extended to these operators.
Indeed, both the implicit defaulting to $_ AND the availability of $_
itself. Which occasionally makes me desire even more pronouns. After all
in a natural language like English we have 'it', 'them', 'we', etc... now
it's obvious that
(i) we can't hope nor desire a full correspondence,
(ii) there _already_ are some analogues of _some_ of the above, but
somewhat more limited in usefulness wrt $_.
Now, one that I've sometimes desired is a two level $_, i.e. a variable,
say, $__ referring to the _second next_ enclosing lexical scope. I am
aware that in this vein one may ask a third analogue and so on, but let's
face it: $_ already covers 95% of cases, my hypothetical var would cover I
guess a remaining 4.5% of cases, and who cares for the rest? E.g.:
for @vert {
put_point $_, $__ for @horiz;
}
Note: I am aware that P6 will already provide other ways to do it, but
this is not in contrast with Perl's TMTOWTDI-ness. I expect it to be
useful enough in nested {map,grep}'s.
Michele
--
you look around what do you see?
I'll tell you what I see is a world belonging to me
- Pennywise, Living For Today.
Re: Pronouns [Re: $_ defaulting for mutating ops]
Michele Dondi skribis 2005-10-25 17:05 (+0200):
Now, one that I've sometimes desired is a two level $_, i.e. a variable,
say, $__ referring to the _second next_ enclosing lexical scope. I am
aware that in this vein one may ask a third analogue and so on, but let's
face it: $_ already covers 95% of cases, my hypothetical var would cover I
guess a remaining 4.5% of cases, and who cares for the rest? E.g.:
for @vert {
put_point $_, $__ for @horiz;
}
I find $__ confusing, and prefer $OUTER::_, which already exists.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Pronouns [Re: $_ defaulting for mutating ops]
On Tue, 25 Oct 2005, Juerd wrote:
Michele Dondi skribis 2005-10-25 17:05 (+0200):
Now, one that I've sometimes desired is a two level $_, i.e. a variable,
say, $__ referring to the _second next_ enclosing lexical scope. I am
aware that in this vein one may ask a third analogue and so on, but let's
face it: $_ already covers 95% of cases, my hypothetical var would cover I
guess a remaining 4.5% of cases, and who cares for the rest? E.g.:
for @vert {
put_point $_, $__ for @horiz;
}
I find $__ confusing, and prefer $OUTER::_, which already exists.
Hmmm... maybe you're right that $__ is too huffmanized (and hence
confusing) but $OUTER::_ is somewhat too few...
Michele
--
A question out of curiousity: who is this Green of Green's functions?
Is he the same person of Green's theorem? :)
Yes. He was also an early environmentalist; hence the current
phrases green this and green that...
- David C. Ullrich in sci.math, Re: Who is Green?
Re: Pronouns [Re: $_ defaulting for mutating ops]
On 2005-10-25 11:17 AM, Michele Dondi [EMAIL PROTECTED] wrote: I find $__ confusing, and prefer $OUTER::_, which already exists. Hmmm... maybe you're right that $__ is too huffmanized (and hence confusing) but $OUTER::_ is somewhat too few... What's confusing about $__ is that it looks too much like $_. In my font, for instance, there's no gap - it's just a longer underline, which is far too subtle a difference...
Re: Pronouns [Re: $_ defaulting for mutating ops]
Michele Dondi skribis 2005-10-25 17:17 (+0200):
Hmmm... maybe you're right that $__ is too huffmanized (and hence
confusing) but $OUTER::_ is somewhat too few...
for (1..9) - $n { # ought to be more than enough
eval qq[
macro prefix:\$_$n { \${ OUTER:: x $n }_ }
];
}
And then you can use $_1 .. $_9. I think $_1 is much clearer than $__,
but I think neither is needed in the standard language.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Pronouns [Re: $_ defaulting for mutating ops]
On Tue, 25 Oct 2005, Juerd wrote:
for (1..9) - $n { # ought to be more than enough
eval qq[
macro prefix:\$_$n { \${ OUTER:: x $n }_ }
];
}
And then you can use $_1 .. $_9. I think $_1 is much clearer than $__,
but I think neither is needed in the standard language.
Can I beg to differ any more? (Implicit answer: no, I can't!)
Michele
--
The trouble with engineers is that given the problem of knocking down
a stack of 100 bricks, they will start at the top, and work all
day removing them one at a time, while the mathematician will, after
a momemt's thought, remove the bottom brick and be done with it.
The trouble part, is having to brook the noise of the engineer
boasting about how much harder he worked while one is trying to
think about the next problem.
- Bart Goddard in sci.math
Re: $_ defaulting for mutating ops
I think it'd be great if +=, ~=, +=, ++, etc, could all assume $_ on their LHS when there is no obvious operand. It'd be nice to have these, but is it something that can wait? I wouldn't mind if more effort was spent on other pieces if this can be easily done in the future - sebastian
Re: $_ defaulting for mutating ops
Sebastian skribis 2005-10-25 9:17 (-0700): I think it'd be great if +=, ~=, +=, ++, etc, could all assume $_ on their LHS when there is no obvious operand. It'd be nice to have these, but is it something that can wait? I wouldn't mind if more effort was spent on other pieces if this can be easily done in the future It can wait, in theory, but implementing this should be trivial for the people doing implementation. One problem with waiting until after the first release is that there will very quickly be code that works with 6.0.1, but not with 6.0.0, if what you're waiting for is a small thing to implement... Things that can wait are usually very non-trivial, and have little impact on the rest of the language. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Pronouns [Re: $_ defaulting for mutating ops]
On Tue, Oct 25, 2005 at 05:26:32PM +0200, Juerd wrote:
: Michele Dondi skribis 2005-10-25 17:17 (+0200):
: Hmmm... maybe you're right that $__ is too huffmanized (and hence
: confusing) but $OUTER::_ is somewhat too few...
:
: for (1..9) - $n { # ought to be more than enough
: eval qq[
: macro prefix:\$_$n { \${ OUTER:: x $n }_ }
: ];
: }
That can't work as is. A macro's syntactic effect is always limited to
a particular lexical scope, which is by default the lexical scope
of the declaration. You'll need to find some way of installing it
into the currently compiling lexical scope, which is going to resemble
something more like:
BEGIN {
for (1..9) - $n { # ought to be more than enough
COMPILING::{term:\$_$n} := macro { \${ OUTER:: x $n }_ };
}
}
Also, $_ has to be a term, not a prefix, or the next thing will
be expected to be a term rather than an operator. But probably
it shouldn't be a macro anyway, since you could just alias $_1 to
$OUTER::_ etc. directly:
BEGIN {
for (1..9) - $n { # ought to be more than enough
COMPILING::{\$_$n} := COMPILING::(OUTER:: x $n)::$_;
}
}
maybe with something to catch the case of too many OUTERs.
Larry
Re: $_ defaulting for mutating ops
On Tue, Oct 25, 2005 at 02:51:35PM +0200, Juerd wrote:
: For comparison, here is the same code snippet again. First with, and
: then without explicit $_.
:
: With:
:
: given ($subject) - $_ {
: $_ ~~ s/foo/bar/;
: $_++;
: $_ x= 2;
: $_ ~= !;
: }
:
: Without:
:
: given ($subject) {
: s/foo/bar/;
Already the default.
: ++;
Can already use .++ there. That's because you can already use . on
any postfix operator, and since any . form defaults to $_, you get
.++ for free. I'll let you have .-- as well. And .! if you define
factorial. :-)
It would be possible to extend . to allow any infix plus its right argument
to be treated as a postfix, presuming there wasn't already a postfix of
that name. However...
: x= 2;
That might validly parse as assignment to an lvalue sub: x() = 2;
Unfortunately .x= 2 doesn't work either, since we also have lvalue
methods. Actually, x=2 should parse as x(=2), since a list operator
always expects a term next. Yes, we *could* throw all the infix
operators into the prefix pot and match them under longest-token, but
the basic problem with the proposal is rampant term/operator confusion.
What should the lexer do when it sees a statement starting with
/=digit*/
%=PODSynopsis.say
*=$*IN
+=
Those could get away with
./= 2
.%= 2
.*= 2
.+= 22
But then you're only saving a character (and maybe a space) over $_.
: ~= !;
That would validly parse as
~(=!)
: I think the latter is more elegant, without reducing legability or
: maintainability. I also think that the code is immediately obvious, even
: to people coming from Perl 5, who never read this thread.
I think you're relying on those people using whitespace to dwym,
but unfortunately people chunk things differently from computers.
And most people will be uncomfortable if the computer uses whitespace
to guess, more so because it's doing lookahead to find that whitespace.
And are you ready to disallow patterns that start with '='?
And basically I don't think people want to mutate $_ with math operators
all that often--and if they do want to, they probably don't. :-)
Larry
