return
if (expr)
for (@array);
... was _not_ going to work? I can't find/recall where the impetus for
that decision was described... anyone remember that one?
MikeL
ML> Apropos of nothing in particular, what was the reason that post-X
ML> chaining, e.g.
ML> return if (expr) for (@array);
ML> ... was _not_ going to work? I can't find/recall where the
ML> impetus for that decision was described... anyone remember that
ML> one?
the biggest problem IIRC was nested loops. how do you bind $_ two or
more times in one expression.
blah($_) for @array1 for @array2 ;
what is $_ bound to?
if/unless are easily done with || and && so they aren't even needed.
expr && return for @array ;
finally, larry said they aren't going to be supported and that is a good
reason all by itself.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Seems like there was some sort of *really* ambiguous precedence issue
somewhere, too...but I'll be darned if I recall what....
> if/unless are easily done with || and && so they aren't even needed.
> expr && return for @array ;
Ick, but yeah.
> finally, larry said they aren't going to be supported and that is a
> good reason all by itself.
True, I suppose, but Larry always has his reasons, and once I get my
brain wrapped around them they're always sound, and usually worth learning.
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
[MikeL asks: why no post-X chaining?]
> the biggest problem IIRC was nested loops. how do you bind $_ two or
> more times in one expression.
>
> blah($_) for @array1 for @array2 ;
>
> what is $_ bound to?
Same thing it would be if I did this:
for (@array2) {
for (@array1) {
blah($_);
}
}
> if/unless are easily done with || and && so they aren't even needed.
Not to reactivate this whole thing, but that argument doesn't hold a
lot of water. I<unless> is not really needed--you can get the same
thing by saying C<if (not $foo)>. Likewise, C<and> and C<or> are not
needed--you can get the same effect with && and || and a bunch of
parens. Come to think of it, you don't really B<need> to be able to
return multiple values, right? You could always just pass a reference
to an array in as an extra parameter, then stuff that array before
returning....
Basically, why draw the line here?
> expr && return for @array ;
Seems fine. Exit the current function unless expr evaluates to false
once for each element of @array...presumably, you are testing
something in @array, but not necessarily.
> finally, larry said they aren't going to be supported and that is a good
> reason all by itself.
Yep, that IS a good enough reason. Like Paul, though, I _would_ like
to understand Larry's thinking. This call seems arbitrary, which is
unusual for Larry. I'd even be happy with "My experience tells me
that this will cause a lot of problems down the road, but I can't put
my finger on why."
--Dks
>On Thu, May 01, 2003 at 04:07:41PM -0400, Uri Guttman wrote:
>
>[MikeL asks: why no post-X chaining?]
>
>>the biggest problem IIRC was nested loops. how do you bind $_ two or
>>more times in one expression.
>>
>> blah($_) for @array1 for @array2 ;
>>
>>what is $_ bound to?
>>
>
>Same thing it would be if I did this:
>
> for (@array2) {
> for (@array1) {
> blah($_);
> }
> }
>
Yes, but that's pretty useless, so why do it?
>>if/unless are easily done with || and && so they aren't even needed.
>>
>
>Not to reactivate this whole thing, but that argument doesn't hold a
>lot of water. I<unless> is not really needed--you can get the same
>thing by saying C<if (not $foo)>. Likewise, C<and> and C<or> are not
>needed--you can get the same effect with && and || and a bunch of
>parens. Come to think of it, you don't really B<need> to be able to
>return multiple values, right? You could always just pass a reference
>to an array in as an extra parameter, then stuff that array before
>returning....
>
>Basically, why draw the line here?
>
It has to be drawn somewhere, or else things will get out of
control (-:
Besides, if you were a maintenance programmer, would you like
to see something like:
# guards gone wild!
foo $_ if(baz) for(@list) unless(quux.next()) while 1;
or:
while 1 {
unless quux.next {
for @list -> $elm {
foo($elm) if baz;
}
}
}
I sure know that I'd choose the latter!
Joseph F. Ryan
ryan...@osu.edu
My most common case is something like:
return 1 if $_.foo
for @array;
Which I would like to write that way, as opposed to any other way,
because that's the way I think of it. I understand that the feature
could be abused, however. The design team nixed it, and I don't have a
particular issue with that; I'm just trying to remember the reason,
because I can't seem to find it in the archives.
Specifically, what I'm trying to remember is the ambiguous case that
someone came up with that precludes us from having this feature.
Things like:
f($_) for @a for @b for @c for @d;
are scary, but they aren't ambiguous, because the $_ refers to the
innermost topic, same as always. I think A4 suggested that the feature
might exist, but I seem to recall that it was nixed fairly recently
because of an actual ambiguity, not just style reasons.
MikeL
That in particular would indeed be nice to do. But, it's not as if
it's all the less readable if you put it on one line with one of the
other WTDI:
for @array { return 1 if .foo }
The fact that parens are no longer required around @array makes this
a lot more tolerable.
> Which I would like to write that way, as opposed to any other way,
> because that's the way I think of it. I understand that the feature
> could be abused, however. The design team nixed it, and I don't
> have a particular issue with that; I'm just trying to remember the
> reason, because I can't seem to find it in the archives.
Well, there was never an actual reason that came from the design team,
other than just a simple "No." Other cases have been made, however.
> Specifically, what I'm trying to remember is the ambiguous case that
> someone came up with that precludes us from having this feature.
> Things like:
>
> f($_) for @a for @b for @c for @d;
>
> are scary, but they aren't ambiguous, because the $_ refers to the
> innermost topic, same as always. I think A4 suggested that the feature
> might exist, but I seem to recall that it was nixed fairly recently
> because of an actual ambiguity, not just style reasons.
I don't recall any ambiguity with chained modifiers. The first time
this came up in my history here is when I asked it I<en passant>, and
Larry just said "No, still can't chain them."
Then it was brought up again by Matthijs Van Duin, proposing a
solution to the problem. Interesting that he could do this,
considering we never knew what the problem was in the first place.
And now it's come back again.
There was an ambiguity regarding statement modifiers and the following
syntax of C<for>:
for @a ; @b -> $a ; $b { ... }
(Which is mute now, as this syntax is gone)
And one related to implicit semicolons, also having to do with
statement modifiers. But there were none as a direct consequence of
multiple modifiers, IIRC.
Luke
I think there was something about C<if X foo if Y>
=Austin
EWW!
if $x foo() if $y;
Ugly!
But let me look at it for a sec....
That's not valid syntax is it? Wouldn't it have to be
if $x { foo() if $y; } #?
Even so, it requires both, so isn't
if $x foo() if $y;
semantically equivelent to
foo() if $x and $y; #?
Not that I'd want to depend on the compiler to get that....
What if it were
if x() foo() if y();
Those could be order dependent. Which comes first? Hmm....
Do I hear a "Don't do that"?
But someone would.....
>> might exist, but I seem to recall that it was nixed fairly recently
>> because of an actual ambiguity, not just style reasons.
>
> I think there was something about C<if X foo if Y>
Ah, Bingo! I think you're right, I think that was it, or something
like it. Thanks.
Of course, that's not directly a chaining-related problem, in that you
only have one postconditional ... so my impression is that that would
indeed be valid syntax now.
if $expr { blah } if $expr2;
Flippin' 'ell, tho, I don't have the foggiest idea what that should be
doing:
(if $expr { blah }) if $expr2; # ???
if $expr ({ blah } if $expr2); # ???
Hmm. Instinct tells me it means the first, because the second suffers
from the is-it-a-hash-or-a-block ambiguity.
MikeL
Actually, you seem to have a fairly non-foggy idea. :>
I would be extremely surprised if it meant anything OTHER than the
first option. The way I have always looked at postconditionals is
"evaluate the postconditional and, if true, do everything to the left
of it."
Dave
And the block is still required on a prefix if, even tho the parens
aren't right?
But that's really ugly.
Do this if this if true, but don't check that unless this other thing
is true.... how easy could you get lost in that? Yeah, the parser might
be able to handle it, but what confidence do you have in the coder's
intent?
"Keep the ramp low."
It adds more complexity than advantage.