Conditional C<return>s?
Michael Lazzaro
canonical way to do this be, given what we know of Perl6?
# the hapless, inefficient version:
...
return &result_of_some_big_long_calculation(...args...)
if &result_of_some_big_long_calculation(...args...);
...
The obvious answers are this:
my bool $x = &result_of_some_big_long_calculation(...args...);
return $x if $x;
-or the identical -
my bool $x;
return $x if $x = &result_of_some_big_long_calculation(...args...);
Is there a way that doesn't require the named variable? Perhaps using
C<when>? Just a thought experiment on my part, reduced from some code
examples that do this sort of thing in a duplicitous fashion,
switch-like...
my bool $x;
return $x if $x = &calc_try_1(...);
return $x if $x = &calc_try_2(...);
return $x if $x = &calc_try_3(...);
...
MikeL
Matthijs Van Duin
> my bool $x = &result_of_some_big_long_calculation(...args...);
> return $x if $x;
>
$_ and return given big_calculation();
or:
given big_calculation() {
return when true;
}
--
Matthijs van Duin -- May the Forth be with you!
Michael Lazzaro
On Monday, March 31, 2003, at 11:18 AM, Matthijs van Duin wrote:
> On Mon, Mar 31, 2003 at 11:04:35AM -0800, Michael Lazzaro wrote:
>> my bool $x = &result_of_some_big_long_calculation(...args...);
>> return $x if $x;
>>
>> Is there a way that doesn't require the named variable?
>
> $_ and return given big_calculation();
>
> or:
>
> given big_calculation() {
> return when true;
> }
Don't those return C<undef>, as opposed to the value of C<$_>? I.E.
wouldn't it be:
$_ and return $_ given big_calculation();
-or-
given big_calculation() {
return $_ when true;
}
MikeL
Jonathan Scott Duff
> Don't those return C<undef>, as opposed to the value of C<$_>? I.E.
> wouldn't it be:
>
> $_ and return $_ given big_calculation();
> -or-
> given big_calculation() {
> return $_ when true;
> }
Personally I'd just use
return big_calculation();
and make sure that big_calculation() returns the right thing.
If you *really* needed the exactly semantics given above, you could put
big_calculation() in a wrapper that does it for you.
-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu
Matthijs Van Duin
Oops, yes, you're right ofcourse
Sorry :)
Paul
--- Jonathan Scott Duff <du...@cbi.tamucc.edu> wrote:
> On Mon, Mar 31, 2003 at 12:12:54PM -0800, Michael Lazzaro wrote:
> > Don't those return C<undef>, as opposed to the value of C<$_>?
> > I.E. wouldn't it be:
> >
> > $_ and return $_ given big_calculation();
> > -or-
> > given big_calculation() {
> > return $_ when true;
> > }
>
> Personally I'd just use
>
> return big_calculation();
I started to suggest this myself, then realized that you might not want
it to return at all if the value is false. Maybe you're looking for the
first nonzero return in a set on inputs:
my $y;
for my $x (@data) {
return $y if $y = big_calc($x);
}
Otherwise, I'd *definitely* just
return big_calc();
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Smylers
> Forgive me; a very minor style & efficiency question... what would the
> canonical way to do this be, given what we know of Perl6?
>
> # the hapless, inefficient version:
> return &result_of_some_big_long_calculation(...args...)
> if &result_of_some_big_long_calculation(...args...);
>
> The obvious answers are this:
>
> my bool $x = &result_of_some_big_long_calculation(...args...);
> return $x if $x;
That does something different, in that it has coerced the result into a
C<bool>[*0]. So after the first line C<$x> can only be 0 or 1[*1]. And
given that one of those states is false, the code becomes equivalent to:
my bool $x = &result_of_some_big_long_calculation(...args...);
return 1 if $x;
or simply:
return 1 if &result_of_some_big_long_calculation(...args...);
However if you permit the function to return more than two different
values (of which more than one are true) then it becomes a more
interesting question.
[*0] Do we have C<bool>? I thought Larry wanted C<bit>.
[*1] Or whatever the two states of a C<bool> are.
Smylers
Piers Cawley
> The idea of a pronoun, something other than $_, has occasionally crossed
> my mind. I haven't given it any real thought, but perhaps this is the
> time.
>
> return it if &baz(...args...);
>
> Something that represents the "last evaluated expression"... or
> something similar that is sufficiently DWIMmy. I'm trying to stay
> away from punctuation variables for fear of repeating Perl 5's
> mistakes.
>
> C<it> might be just the thing... now all that has to be done is come
> up with semantics. And decide whether it's a good idea.
I could be getting ahead of myself here, but I wouldn't be at all
surprised to find that it will be possible to implement 'it' or
something like it in pure Perl 6. At least, I hope it will.
--
Piers
Piers Cawley
> Paul writes:
>
>> My P6 syntax is still weak, though. Maybe
>>
>> given big_calc() { return $_ if $_ }
>
> Using C<for> works in Perl 5. Is there anything preventing this working
> in Perl 6:
>
> for big_calc() { return $_ if $_ }
Context. 'for' provides a list context.
--
Piers
Paul
Ok, just for fun....
Check my P6, someone?
my macro it { "\$_" }
# time, space, and code passes....
return it when foo(@bar);
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Paul
> my macro it { "\$_" }
hMMM....
Maybe that would be better written as
my macro it { '$_' } # replace "it" with '$_"
so that there isn't any confusion about references?
I assume you can't just say
my macro it { $_ } # uses the value?
because the macro happens at compile time, and $_ would be evaluated to
no useful value and probably give you a miscompile?
Austin Hastings
Yeah, this is sounding like one of those really, really bad ideas. I'm
thinking that dynamic creation of local variables solves this problem
the way I want it to be solved:
if (my $it = big_calculation()) return $it;
As opposed to some OTHER way of reaching arbitrarily backwards in the
execution path for data:
big_calculation();
if (@RESULT[-1]) return @RESULT[-1];
I'm wondering if what's needed *to address the specific question asked*
isn't already covered in Perl's semantics (maybe just needing a little
clarification):
sub Int some_calc()
{
if (big_calc()) return;
other_calc();
}
We are accustomed to the "return the accumulator" behavior of Perl when
dealing with the end of the block. Everyone should be comfortable with
the implied return of the result of other_calc, above. So making
explicit that a leave statement without a value argument implicitly
uses the last computation would be okay. (I know it might interfere
with optimization, so I would compromise and say that this should be
true ONLY when a signature is available demanding a result -- that is:
sub foo()
{
$y++;
if ($x) return;
stuff();
}
The lack of a return-type-indicator means that the compiler COULD
potentially return $y instead of $x, due to optimization.
sub foo()
returns Scalar
{
$y++;
if ($x) return;
stuff();
}
In this case, the requirement to return something means that the last
evaluated expression ($x, or stuff()) will be guaranteed to be
returned, regardless of the convenience of the optimizer.
What about THAT, Mr. Fong?
=Austin
Larry Wall
:
: Ok, just for fun....
: Check my P6, someone?
:
: my macro it { "\$_" }
: # time, space, and code passes....
: return it when foo(@bar);
Won't work because C<when> doesn't set C<$_>. You need a C<given>.
Larry
Paul
> : return it when foo(@bar);
>
> Won't work because C<when> doesn't set C<$_>. You need a C<given>.
d'oh. Then
my macro it { '$_' }
return it given foo(@bar);
??
Smylers
> Smylers <Smy...@stripey.com> writes:
>
> > Paul writes:
> >
> > > My P7 syntax is still weak, though. Maybe
> > >
> > > given big_calc() { return $_ if $_ }
> >
> > Using C<for> works in Perl 5. Is there anything preventing this
> > working in Perl 6:
> >
> > for big_calc() { return $_ if $_ }
>
> Context. 'for' provides a list context.
Does that matter? So long as C<big_calc()> returns a single scalar
value -- which presumably is the case in the situation being discussed
-- what's the harm of it being evaluated in a list context?
Smylers