Okay, we've traded a simple, extensible, easily used and self-documenting construct for YAKW and less self documenting code.

I often use

...
my( $p, $i ) = 0;
$p += $i while $i = 1+index $haystack, $needle, $i;
...
[download]

Sometimes, when debugging I need to see what is going on, so I wrap the code and add some debug:

...
my( $p, $i ) = 0;
do{ 
    $p += $i;
    print "$p : $i, other stuff";
} while $i = 1+index $haystack, $needle, $i;
...
[download]

Once I'm done debugging, I can just comment out the print lines and I am back to where I was.

In p6, I will have to completely change the coding of the single line with modifier version of the loop to an alien and less clear construct when I need to debug, and convert it back once I have the logic correct. Or leave as that strangly Fortran IV-ish form:

my( $p, $i ) = 0;
loop {
    $p += $i;
    last if $i = 1+index $haystack, $needle, $p;
}
[download]

I know "LW is always right" and "LW is always right even when he is wrong", but on this I think he has never been more right.

From the limited evidence of this particular article, you seem to be unaware that you've switched from test-before semantics to test-after semantics, which can completely foul things up on loops that need to be able to execute 0 times, or that have side effects in the conditional. So it's quite possible you've just proven the argument you were trying to disprove. :-)

Mea culpa. Actually, the example code I typed in doesn't make much sense in any case. I should have taken the time to produce a tested example.

I wasn't trying to disprove anything, just commenting in keeping with the thread. However, perhaps I should state my objection more directly. The transition from test-before to test-after is (to my knowledge) unique with this combination of do BLOCK and while. In every other case, the modifier is evaluated before the statement that is modified.

I understand (or at least I think I do), that this was done to provide for the pascal-style test-after loop construct. My problem with the decision to ban the while modifier on do blocks is that it is (IMO) the wrong way to fix the misconception that I so nicely fell into with my examples.

I think that the misconception arises because in every other case, substituting a do block for a single statement has exactly the effect of grouping its contained statements that one expects. So, it's the special case that causes the problem.

So rather removing what would otherwise be a useful construct, I'd prefer that the special case was removed.

As the loop keyword has been designated, would it be too confusing to use

loop{ 
    ... 
} while condition;
[download]

?

Don't feel the need to debate this further. I missed (and haven't found despite having looked for the original decision point a couple of times), the arguments behind the decision, but I accept that you've probably given this much more thought than I, and you usually get these things right.

I also fit in that camp of people that would like to use multiple statement modifers, but accept you have good reasons for your distaste for those also.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon