Groups | Search | Server Info | Login | Register


Groups > comp.lang.perl.misc > #4772

Re: $var = do { ... }?

From Rainer Weikusat <rweikusat@mssgmbh.com>
Newsgroups comp.lang.perl.misc
Subject Re: $var = do { ... }?
Date 2012-03-16 17:46 +0000
Message-ID <87mx7gh21q.fsf@sapphire.mobileactivedefense.com> (permalink)
References <jiqv7d$6k4$1@reader1.panix.com> <jjt7p5$e3g$1@reader1.panix.com> <4f633b3d$0$6845$e4fe514c@news2.news.xs4all.nl>

Show all headers | View raw


"Dr.Ruud" <rvtol+usenet@xs4all.nl> writes:
> On 2012-03-15 18:09, Tim McDaniel wrote:
>
>> So I have to make sure the code evaluates the desired return value as
>> the last thing in the block, like
>>
>>      my $result = do {
>>          if ($i % 2 == 0) { 'even' }
>>          elsif ($i % 3 == 0) { 'divisible by 3' }
>>          elsif ($i % 5 == 0) { 'divisible by 5' }
>>          else { 'just wrong' }
>>      };
>>
>> Is there a clever way in Perl 5 to metaphorically return early with a
>> value?
>
> That if/elsif/else of yours already does that. Remember that
> perl-the-binary compiles to opcodes. So the 'elsif' is only done if
> the 'if' didn't do.

"When the program compiles, the machine is happy" (R. Pike). But since
code is not write-only, there should be other considerations beyond
'making the machine happy'. The way and if - else construct works is
that it provides, based on some set of conditions, a set of
alternative codepaths to follow at some point of an otherwise linear
movement, ie, after one of the alternate code paths was chosen,
execution is supposed to continue with the next statement after the
if. People tend to use it even if no such next statement exists, at
least partially cause by a misunderstanding of some statement about
'structure programming', namely, that 'a module' (subroutine) should
have a single entry and exit point. This essentially doesn't make any
sense[*] in language designed with this dictum in mind because
subroutines always have a single entry point and they always have a
single exit point (that's the location where execution of the calling
code continues after the subroutine finished(!)). Later, this
statement has been re-interpreted to mean that the control-flow inside
a subroutine should be contorted to give the illusion as if all
possible codepaths through the subroutine would 'naturally' end after
the last statement in the corresponding block. And that's IMO not a
good idea.

Back to comp.lang.perl.misc | Previous | NextPrevious in thread | Find similar


Thread

$var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-02 17:15 +0000
  Re: $var = do { ... }? merlyn@stonehenge.com (Randal L. Schwartz) - 2012-03-02 09:52 -0800
  Re: $var = do { ... }? Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2012-03-02 13:42 -0500
  Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-02 18:44 +0000
    Re: $var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-02 19:00 +0000
      Re: $var = do { ... }? merlyn@stonehenge.com (Randal L. Schwartz) - 2012-03-02 11:45 -0800
      Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-02 20:06 +0000
  Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-02 19:18 +0000
    Re: $var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-02 19:24 +0000
      Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-02 20:10 +0000
        Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-02 20:43 +0000
          Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-02 22:47 +0000
          Re: $var = do { ... }? Martijn Lievaart <m@rtij.nl.invlalid> - 2012-03-03 15:58 +0100
            Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-03 17:11 +0000
              Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-03 17:19 +0000
              Re: $var = do { ... }? Martijn Lievaart <m@rtij.nl.invlalid> - 2012-03-03 23:58 +0100
                Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-04 00:29 +0000
                Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-04 14:44 +0000
                Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-05 20:50 +0000
        Re: $var = do { ... }? "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2012-03-05 11:35 +0100
          Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-05 15:22 +0000
          Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-05 16:38 +0000
      Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-02 20:44 +0000
  Re: $var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-15 17:09 +0000
    Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-16 00:18 +0000
      Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-16 14:25 +0000
        Re: $var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-16 21:01 +0000
          Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-16 21:37 +0000
          Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-16 22:56 +0000
            Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-16 23:54 +0000
            Re: $var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-17 18:48 +0000
              Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-17 22:53 +0000
              Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-18 15:40 +0000
    Re: $var = do { ... }? "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2012-03-16 14:08 +0100
      Re: $var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-16 15:25 +0000
      Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-16 17:46 +0000

csiph-web