Re: Re: Taken out of Context

[Petruchio]

Thank you for the reply, and for the link to the well-written and informative article. I'm afraid, however, that it seems a little beside the point.

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.

[japhy]

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