Interesting point. I hadn't considered Perl 6, I'm trying hard not to get excited about until it's a little closer to fruition.

When you say "the for will probably be translated to a given", do you mean by an automated process? Is there an intention to provide a p5top5.pl or binary? I thought that the route was to have a p5 'mode' rather than conversion?

Given all the different ways the scalar value in the for loop could be provided

for ($scalar) {...}
for (funcReturningScalar()) {..}
for ($hash{of}{some}{arbitrar}{size}{returning}{scalar}) {...}
for($$hash{returning}{refToScalar}) { ... }
# Many more
[download]

Unless this p5top6 processor is going to act at the bytecode level, its going to have to be a fairly sophisticated piece of code to catch all the possible variations where the topicaliser of the for returns a scalar and not a list? Would it be that much more work to have it check to see if the first line inside a bareblock was local $_ = expression; which by definition must be assigning a scalar?

Thinking about this further, I'm not sure I understand though. As given is a case-type construct, converting a one-time for to a given would result in some strange code

for ($scalar) {
    # do stuff;
}
[download]

Becoming

given ($scalar) {
    when <<always>> {
        # do stuff;
    }
}
[download]

I'm not quite clear how you would express the always? Though I assume given will have an equivalent of C's default: clause, so I guess it could become

given ($scalar) {
    default {
        # do stuff;
    }
}
[download]

But I'm not sure that's much better.

---

Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!

There is a very significant difference: your second snippet isn't aliasing anything, it's making a local copy.

I tend to use for as a topicalizer for single expressions, as a statement modifier. It would be cumbersome to bloat those into a naked block with a local, and will often not even do what I want since I'm actually intending to change the original variable. A silly example would be s/nit// for $style;

For temporary variables, which was what this thread really was about, I use local. Not only does a for block not do what I want anyway (except (close your eyes) in the perverted for(my $temp) { ... } form (now open them again)) because it aliases a variable rather than give me a fresh, empty one, but it also adds another indentation level, which in my stylistic preference is to be avoided at all cost.

for and local are really orthogonal to each other. Neither can do what the other does, and so debating which one is preferred is moot.

Makeshifts last the longest.

second snippet isn't aliasing anything

Good point. It would have to be

$_= 'value before localising';
my $thingToAlias =  'the quick brown fox';
{
    local *_= \$thingToAlias;
    s/brown//;
}
print $thingToAlias;
print $_;
[download]

Giving

C:\test>test
the quick  fox
value before localising

C:\test>
[download]

A silly example would be s/nit// for $style;

I can't see any advantage in this over $style =~ s/nit//;?

I appreciate this was just a trivial example, but I can't see where this would be useful as a statement modifier? (No doubt you have a great example up your sleeve:^)

For temporary variables, which was what this thread really was about, I use local. Not only does a for block not do what I want anyway (except (close your eyes) in the perverted for(my $temp) { ... } form (now open them again)) because it aliases a variable rather than give me a fresh, empty one, but it also adds another indentation level, which in my stylistic preference is to be avoided at all cost.

for and local are really orthogonal to each other. Neither can do what the other does, and so debating which one is preferred is moot.

Agreed. They are unrelated, but I was responding to Re: Using $_ as a temp var, especially in functions in the second part of my post rather than the OP.

I first saw the 1-time for when you showed it to me in a thread about a week ago (which I can't now find?) but I was uncomfortable with the idiom of using a loop for a straight through peice of code. I'm similarly troubled by the use of redo in a bare block or if statement, prefering to see a loop construct where things are going to loop.

I did spend a while after you first showed me the 1-time for looking for a suitable alternative. And came up with the local *_ = \$variable; (Which in turn was stolen from the Cheap idioms thread.), but promptly forgot the detail as I haven't had a need to use it yet. That's also why I was interested in the arguments against it.

Who knows, maybe in time I'll get used to these idioms as I have others and go with the flow (sic), but as I said, my devlopment of a personal style, and my investigations of what's possible in perl is ongoing.

---

Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!

You are right, that example is silly, which is why I said so. :^) It's useful (as that thread was discussing btw) for something like $_ eq "pot" and ($_ = "kettle") for $some->{deeply}{nested}{data}{structure}; The straight alternative is

$some->{deeply}{nested}{data}{structure} = "kettle"
    if $some->{deeply}{nested}{data}{structure} eq "pot";
[download]

which irritates my hubris. Localizing here is better than that, but it's just too much red tape for my taste:

{
    local *_ = \$some->{deeply}{nested}{data}{structure};
    $_ = "kettle" if $_ eq "pot";
}
[download]

local *_ = \$something; is not a language construct, I have to brainparse it and understand what's going on to read the code.

I see where you object to a loop that has only one iteration, although I find the use of redo in a naked block far worse than a single-iteration for loop: the redo conceils the loop character because you don't know that that naked block is one until you read to an arbitrary point inside it. for used as a topicalizer on the other hand makes it immediately obvious that we're only looking at a single iteration.

The example you gave where a function's return value is topicalized misses the point. You topicalize a variable when you intend to modify it - doing that to a function return value you haven't saved is pointless. You might of course do something like this:

my $stuff;
for(return_value()) {
    chomp;
    s/foo//g;
    tr/x/y/;
    $stuff = $_;
}
[download]

But if I had to maintain that I'd hunt you down and kill you. That obviously should have been

my $stuff = return_value();
for($stuff) {
    chomp;
    s/foo//g;
    tr/x/y/;
}
[download]

For the record, I actually don't use the long construct with the for block frequently either. It does come in very handy when it's appropriate though. (I got the idea of using for as a topicalizer from the man himself actually - he mentioned this in an interview, where he said it Perl has a topicalizer, for, which lets people say "it", ie $_, without specifying the subject over and over.)

That's what I have to say on the issue. YMMV :-)

Makeshifts last the longest.