after all, *a = *b; is equivalent to *a = \*b; ("equivalent" being the Third Camel's word, not mine).

Could be list context. It should be easy to see their return values in standard output, since print() takes things in list context...

> perl -e 'print *b,"\n";'
*main::x
> perl -e 'print \*b,"\n";'
GLOB(0x80d1f44)
[download]

Hmm... maybe not. In list context, they return different values. Scalar context?

> perl -e 'print scalar(*b),"\n";'
*main::x
> perl -e 'print scalar(\*b),"\n";'
GLOB(0x80d1f4c)
[download]

Doesn't seem so. Well, but there are different scalar contexts. Now the Camel promises that "operations never know or care which scalar context they're in", but I'm willing to try them anyway. There's numeric context:

> perl -e 'print "$_\n" for (0..*b);'
0
> perl -e 'print "$_\n" for (0..\*b);'
0
1
2
3
4
5
6
7
(and so on)
[download]

Interesting... but still quite different. Boolean context?

> perl -e 'print "Yup\n" if *b;'
Yup
> perl -e 'print "Yup\n" if \*b;'
Yup
[download]

Well, that's something. But there are only two possible results, I believe, for boolean context; true and false.

> perl -e 'print "Yup\n" if 1;'
Yup
[download]

So it seems that 1 returns the same thing in boolean context that *b does; it returns true. However:

> perl -e '*a = 1; print *a,"\n";'
*main::1
> perl -e '*a = *b; print *a,"\n";'
*main::b
[download]

makes it seem like it can't be boolean context either. Didn't make much sense anyway. Same thing applies to void context; not only does it not make sense, but *x and 1 seem to have (or lack?) the same return value (as far as I can figure, which isn't all that far).

String context? Well, to be doubly sure that what I tried before was stringy, I'll say:

> perl -e '$x = "-> " . *b . " <-"; print "$x\n";'
-> *main::b <-
> perl -e '$x = "-> " . \*b . " <-"; print "$x\n";'
-> GLOB(0x80d1f80) <-
[download]

"Don't care" context seems like it must be equivalent to one of the other scalar contexts... and that runs me fresh out of the contexts listed in the Camel's glossary. Chapter 2 also mentions a interpolative context, which may or may not be fair to call a context in the same sense as scalar and list contexts. But in any case, by definition, "interpolative context only happens inside quotes, or things that work like quotes", and *b is not quoted in the code in question (aside from the single quotes which the shell grabs).

So... can it be? Eureka! I've discovered a new context! ;-)

Okay, I'm being a little silly. However while I know that "Perl automatically dereferences the typeglob reference for you", that doesn't really answer the question. When does Perl automatically dereference the typeglob reference? Not in any clear way in the examples above. It does so it when the lvalue is a typeglob; it does it in what *seems* to be another context, a "typeglob context".

Now I'm playing a little loose here, and my reasoning may well have holes in it; I trust my bretheren will be considerate enough to stomp the unsound parts to bits for my benefit.

But isn't it interesting that such a line of inquiry even makes sense?

Look at what the Camel says about interpolative context: perhaps it's not fair to call it a context in the same sense as scalar and list contexts. (Then again, maybe it is.)

Maybe? Hang on... this is a programming language! The implementation details are known right down to the bones; for a given instance of the perl binary, how the language works is not in question.

But interpolative context is. This is what's interesting about all this to me: the notion of different models being better or worse for describing a programming language, an unambiguous piece of engineering. Knowing how it works is, apparently, not enough to answer the question.

So far as I've seen, nobody speaks about C or Java in such terms. Perhaps because the theory normally dictates the structure of programming languages, rather than inspiring them, and later describing them?

Well, food for thought anyway. A linguist's fingerprints are certainly visible here.