> -----Original Message-----
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 18, 2003 4:34 PM
> To: Language List
> Subject: RE: Control flow variables
>
>
> On Tue, 18 Nov 2003, Austin Hastings wrote:
>
> > This seems excessive, but easily discarded during optimization.
> On the other
> > hand, I don't trust the "last statement evaluated" behavior for
> loops, since
> > the optimizer could very well do surprising things to loop statements.
> > (Likewise, however, for scalar control structures.)
>
> This shouldn't be a problem. If there's potential ambiguity then the
> optimization can't be applied. Modulo optimizer bugs you'll be fine.
>
That's the problem I have with it. I'm inclined to believe that the
optimization is more important than the postcondition, most of the time.
On the gripping hand, I *really* like "Damian's Simple Rules for Control
Flow Return Values". So much so that I can easily see a bunch of idioms
coming up around them.
First:
return if (some hideously long and possibly expensive guard);
That one just rocks. It's like:
$_ = &expensive();
return if;
<Singing Frank Zappa>
Valley Perl .. It's .. Valley Perl
like .. return if
when...ever
duh!
</>
Second:
I'm way not sure about how the vector context result of iteration structures
will work. Specifically, what happens when a loop forks a thread, or passes
to a parallelized coroutine? There may not actually BE a result. (Of course,
in a right-thinking system this will be noted, and replaced by a placeholder
object that will "wait" for the result if evaluated.)
Third:
The scalar count of iterations will make it seem that C<for> is a
macrification of C<map>, which isn't necessarily bad. In fact, I can see
this:
$count = for [EMAIL PROTECTED] -> $a {
check($a) or last;
}
if ($count != @a) { fail; }
Leading to:
if (scalar(@a) != for [EMAIL PROTECTED] -> $a { check($a) or last; }) { fail; }
Which leads to C<map>/C<grep> pretty directly:
if grep {!check($^a) } @a { fail; }
So it should actually help with the newbie learning curve, providing an easy
transition from loops to map/grep.
Which really is a good thing.
=Austin
