Can this be done (by a noob :))
in [Perl]
|
Prev: piped open and shell metacharacters
Next: FAQ 8.27 What's wrong with using backticks in a void context?
From: J�rgen Exner on 31 Jul 2010 15:36 Martijn Lievaart <m(a)rtij.nl.invlalid> wrote: >On Sat, 31 Jul 2010 09:35:27 -0700, sln wrote: >> Beware that if $page is generated html, using a regex on it as in [...] >> It can be parsed with regex's > >However, that is a bad isea generally. Or more to the point: parsing HTML, which is _context-free_, using true _regular_ expressions is impossible. And even using the much more powerful enhanced REs from Perl is nothing a sane mind would attempt. jue
From: J�rgen Exner on 31 Jul 2010 15:42 Ben Morrow <ben(a)morrow.me.uk> wrote: >> Why not move the loop condition into the loop condition? >> >> my $page = get "$pbase?page=$pcnt&pid=$pid"; >> while ((!$page =~/No sorties/) and (!$page =~/"sid=$lproc"/)) { >> append_file( "c:/scr/$pid.txt", $page ); >> $pcnt++; >> $page = get "$pbase?page=$pcnt&pid=$pid";} >> } > >Yuck, you've just done the 'get' twice. DRY is *far* more important than >'structured programming', unless you're going to attempt to prove the >program's correctness. > >> Yes, I know the condition could be formulated better, but I transformed >> it as little as possible to demonstrate how the exit() cond can >> trivially be moved into the while() cond. > >Not without duplication of code. Well, fine, then just move the get() call into the condition itself: while (($page = get "$pbase?page=$pcnt&pid=$pid") and (!$page =~/No sorties/) and (!$page =~/"sid=$lproc"/)) { Personally I don't particularly like this approach because the get() doesn't contribute to the condition and exists only for its side effect, but there is no code duplication any more. jue
From: Sherm Pendley on 31 Jul 2010 15:47 Jürgen Exner <jurgenex(a)hotmail.com> writes: > Sherm Pendley <sherm.pendley(a)gmail.com> wrote: >> >> while(1) { >> last unless foo; >> last unless bar; >> last unless baz; >> ... >> } >> >>Which form to use is best judged on a case-by-case basis, with the >>goal being readability. > > I would almost agree. But when _I_ see a while() loop, then I am looking > at the while() condition to determine, under which condition the loop is > being executed and also to determine which post condition will hold true > after the loop has terminated. > Personally I am very much in favour of having one entry and one exit > from a loop rather than searching for an unknown number of exit points > scattered somewhere deep down in the who-knows-how-long loop body. I think we agree more than not - note that I grouped the conditionals at the top of the loop body, with the ellipses representing additional code appearing after them. I wouldn't scatter them throughout the loop body, unless I had a *very* good reason for doing so. sherm-- -- Sherm Pendley <www.shermpendley.com> <www.camelbones.org> Cocoa Developer
From: Ben Morrow on 31 Jul 2010 15:58 Quoth "Peter J. Holzer" <hjp-usenet2(a)hjp.at>: > On 2010-07-31 16:42, J�rgen Exner <jurgenex(a)hotmail.com> wrote: > > "Thomas Andersson" <thomas(a)tifozi.net> wrote: > >>The loop has been rewritten and workds as intended now, using last to exit > >>on the two possible conditions. Now look like this: > >> > >>while (1) { > > > > Ouch, this hurts! Usually this line indicates a deamon which is never > > supposed to terminate. > > Maybe. Personally I never use while (1), I prefer for (;;) instead. > But neither implies that the loop is really infinite: It may (and often > is) be left with last or return. Actually it will *always* be left in some way, if only due to the heat death of the Universe... :) To me while (1) and for (;;) imply 'I don't yet know when or why this loop will terminate'. Since this is often the case, they are useful constructions. (It may (or may not) be worth noting that Perl 6 has a dedicated flow-control keyword, 'loop { ... }', for infinite loops.) Ben
From: Ben Morrow on 31 Jul 2010 16:05
Quoth J�rgen Exner <jurgenex(a)hotmail.com>: > > I would almost agree. But when _I_ see a while() loop, then I am looking > at the while() condition to determine, under which condition the loop is > being executed and also to determine which post condition will hold true > after the loop has terminated. > Personally I am very much in favour of having one entry and one exit > from a loop rather than searching for an unknown number of exit points > scattered somewhere deep down in the who-knows-how-long loop body. It > just makes reasoning about the loop a lot easier. To my mind a who-knows-how-long loop body (by which I mean anything more than about a screenful) is a mistake in and of itself. Most of the code should be moved into functions, so that seeing when the loop might finish is easy. And, of course, said functions should (almost) *never* use the fact you can call 'last' to exit a loop somewhere further up the call stack. > But it's certainly a matter of style, at least as long as you don't try > to do any formal program verification. Each additional exit point adds > another proof requirement. I don't know much about proving programs, but do additional exit points really make it any harder than stuffing everything into the conditional? Either way, you end up having to deal with the complexity of the algorithm somewhere. Ben |