I'm really not asking how to get something done, or how Perl behaves under certain circumstances. If that were my concern, it would be false laziness on my part to bother people with questions before I'd Read The Fine Manuals. What interests me are the generalizations we make to describe how Perl behaves.

For instance, take your statement:

Thus, you can use a glob where you would ordinarily use a reference to a glob.

Can I? Well, if I ordinarily said:

> perl -e '$y = '*main::z'; $x = \*y; print $$x,"\n";'

And expected Perl to reply:

*main::y

Then I should be able to use a glob instead:

> perl -e '$y = '*main::z'; $x = *y; print $$x,"\n";'

And expect the same reply. Instead I get:

*main::z

Now I know you know this; it's evident from looking at the Passing Globs section of your article. But your generalization about Perl's behavior doesn't hold in all cases.

Of course you do qualify: where references are expected but that brings us around to my point. How do I know what's expected? You don't mean where references are expected by Petruchio, the programmer, but where they're expected by Perl. How do we characterize such expectations when talking about Perl? We invoke the notion of context. Your generalization works if you assume a certain context, but it is only valid within that context.

I hope you see what I'm getting at. We could talk about Perl in a lot of ways. We could say that the program

> perl -e 'print 1+1,"\n";'

will print

2

and that

> perl -e 'print 1+2,"\n";'

will print

3

and so on and on and on, but (unimaginably enormous) collections of facts such as these aren't helpful for humans trying to understand Perl.

We can resort to a more abstract approach, and simply read the source code without fear of being mislead; but while that may be necessary to truly understand Perl, I doubt whether that's sufficient either. Frankly, if Larry (as he says) gets confused and has to resort to very high level abstractions to understand Perl, I don't think there's much hope for humans in general to simply swallow that much code whole without conceptually reducing it.

So we're left making generalizations about Perl... reducing various behaviors to certain principles which we can apply to predict behavior. One of these generalizations we call "context".

Now if Perl had "theoretical axes to grind", it seems likely that the theories which guided the creation of the language would be unambiguous and reliable. Perl, however, seems to grow along whichever paths seem convenient, without feeling obliged to adhere to theory. Thus it is much harder to characterize adequately.

I guess my real concern here is the adequacy of the model into which I seek to fit Perl, in order to understand it properly. If taking that model too seriously is going to leave me with conceptual blind spots, I want to know.

In any case, though, I look forward to reading your article at length when I have time, and giving it the careful attention it deserves. Thanks for the reply.

I do realize the error in my generalization about using typeglobs and refs to typeglobs. Thanks for pointing it out as a false generalization.

japhy -- Perl and Regex Hacker

Firstly, I wanted to say that I enjoyed your article. It's well written and very informative. :-) However, I noticed a small (debatable?) bug in your one_each() function.

The problem is that you don't check to make sure that the function is being called on the same two arrays each time. Consider:

my @a = qw(a0 a1 a2);
my @b = qw(b0 b1 b2);
my @c = qw(c0 c1 c2 c3 c4);
my @d = qw(d0 d1 d2 d3 d4);

print '(',join(',', one_each(@a, @b)),")\n";
print '(',join(',', one_each(@a, @b)),")\n";
print '(',join(',', one_each(@c, @d)),")\n";
print '(',join(',', one_each(@c, @d)),")\n";
[download]

It prints:

(a0,b0)
(a1,b1)
(c2,d2)
()
[download]

So, even though you're giving it two new arrays in the second two calls, it uses the position and size from the first two calls. I think an easy way to "fix" this would be to store a copy of the references to the arrays in one of your closure variables and compare it to the references passed in each time, resetting if they're different. Or, perhaps, if you didn't want the position to reset even if you use different arrays, you could just not store the sizes but, rather, check them from the arrays themselves each time. That way the sizes would be correct without resetting the position.

*shrug* Up to you, though. Just thought I'd mention it. Again, props for a well done article.

bbfu
Seasons don't fear The Reaper.
Nor do the wind, the sun, and the rain.
We can be like they are.