Argh!

[swestrup]

Here is but one snippet to illustrate why working with _sps_'s perl code can sometimes hurt my brain:

local ($list)='';
s#(^|\n\n+)(\t?)##"\n".('<p>','<ul><li>','</ul><p>','<li>')[length($list) * 2 + length($2)].($list=$2, '')#gse;
s#$#</ul>#s if $list;

--

It was when I realized he was using side-effects on $list to communicate between the various repetitions of the substitutions caused by /g that my brain started to hurt...

Comments

[(Anonymous)]

Dude, can I help it if Larry's weirder than even me? I'm just trying to think in Perl!

(Of course, what this is about is that the $n substitutions are fatally flawed in that they don't provide the tree-structured namespace necessary to deal with iteration. Larry's also a bit short-sighted on occasion.)

(And I didn't compile any of the input data into regexps, did I? See how good I'm being today?)

[sps.livejournal.com]

Damn, I cam unlogged again.

[swestrup]

Yeah, I worked it out and moved on, but its just one of the places where I said 'Argh!' during the code review.

It looks like changing the code to output wiki-format files will be trivial, now that I actually understand what the existing code does.

[sps.livejournal.com]

By the way, it's not that I'm unwilling to hear about a nicer way of doing this, you understand!

[pphaneuf.livejournal.com]

It's kind of ironic that you'd pull off that crazy, tricky bit of Perl, but incorrectly use "local" instead of "my", a common newbie mistake. Heh.

Unless I am mistaken and I am missing out on a small detail. Wouldn't surprise me.

[swestrup]

IIRC 'my' doesn't work correctly in the context of code inside Perl regular expressions. Or at least it didn't. I think that there is a better way to code the whole routine now, but seeing as it was written 5 years ago, the required features may not have existed yet.

[pphaneuf.livejournal.com]

I think it does, but using "my" inside of a regex (as opposed to using a "my"-declared variable in one) could be iffy. I wouldn't be surprised if the scratchpads were destroyed between two "/g" substitutions, for example, so the whole keeping state thing wouldn't work. But the way this code was written, it looks like just replacing "local" with "my" would be it.

Perl 5 didn't change all that much in the last 5 years, that I know of. Added a few keywords, but nothing too serious (like "our", the opposite to "my", but it's just syntax-sugar).

In this particular case, the "local" wouldn't hurt, and would actually provide what would look like a local variable. But if you start calling some of the functions in the same package, woo, you can get into fun trouble!

[sps.livejournal.com]

You're very young, aren't you? Of course, I could say the fact that Larry originally provided us with "local" and not "my" is a common newbie mistake, too.

Though the following does work, which is something:

my %a = (x => 1);

{ local $a{x} = 0;
  print "Zero: $a{x}\n"
}
print "One:  $a{x}\n"

Experiments show, however, that pos() and substr(), though lvalues, are not local()isable. This is sad. Localising pos(), in particular, would be a great comfort.

[sps.livejournal.com]

PS Why on earth would a newbie use local()? The docs are now (a) hidden and (b) make it insultingly clear that it doesn't do what you want, to the point of concealling what it does do (which is very occasionally useful when doing metapproximative recursion, for example).

[pphaneuf.livejournal.com]

Well, I guess the part about being hidden doesn't help too much! Actually, I don't know how they figure out to use local() in that way. All I know is that every term or so, one of the coop student working on our Perl testing framework uses it incorrectly, is astonished at its behaviour, and needs to be pointed at "my". Sigh.

The next time it happens, I'll ask them how they came up with it.

[pphaneuf.livejournal.com]

Well, I'm told the code is 5 years old, and while yes, I am young, as I only started using Perl with 5.004, this was a solid 10 years ago, and it did have "my" at that time. Now, I wasn't there for Perl 4 or older, but a decade, these days, is nothing to sneeze at, and I think even Debian users have seen a release or two in that kind of timeframe (which is saying a lot!).

I don't understand what is surprising about that piece of code. "local" saves the value, so you can fiddle with it locally, and restores it at the end of the scope. Yep, that's what it did, sure enough. It's a pretty clear (and very useful when there are a lot of global variables, like I think it was mostly in the time of Perl 4) mechanism, it's just quite unfortunately named. Maybe it should have been "localize", to express more that it's something you do to an existing variable, rather than declaring a brand-new local variable?

[sps.livejournal.com]

Actually, I know. It's by reading legacy code and/or old camels.

[sps.livejournal.com]

Boy, I remember how excited I was when Perl 5 arrived....

The programme that comes from is probably more than five years old (I don't think I was at McGill yet), but the origin of the snippet dates back more like fifteen years - we used Perl for sgml wrangling in Chicago, back when gopher was the it.

[swestrup]

The snippet dates from when you were at Softguard, but before I was, so yeah, I guess that was over 5 years ago. I have no idea if it was canabalized from older code, or not.