Re^3: Useful uses of redo?

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.

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

Comment on Re^3: Useful uses of redo? Select or Download Code

Replies are listed 'Best First'.
Re^4: Useful uses of redo? by TimToady (Parson) on Aug 31, 2004 at 00:50 UTC
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. `:-)`	[reply] [d/l]
Re^5: Useful uses of redo? by BrowserUk (Patriarch) on Aug 31, 2004 at 01:53 UTC
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	[reply] [d/l]