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;
-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(...); ...
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; }
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();
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.
On Mon, Mar 31, 2003 at 12:12:54PM -0800, Michael Lazzaro wrote: >On Monday, March 31, 2003, at 11:18 AM, Matthijs van Duin 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; > }
Oops, yes, you're right ofcourse
Sorry :)
-- Matthijs van Duin -- May the Forth be with you!
--- Jonathan Scott Duff <d...@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
Michael Lazzaro writes: > 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>.
Luke Palmer <fibon...@babylonia.flatirons.org> writes: > 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.
> Luke Palmer <fibon...@babylonia.flatirons.org> writes: > > 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
__________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com
> Luke Palmer <fibon...@babylonia.flatirons.org> writes: > > 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.
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.
> > 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?
