Returning SCALAR for GLOBs would definitely be incorrect. GLOBs contain scalars, not the other way around.

Not exactly. A glob is really a kind of a scalar value, just like an integer or a string is.

(Update 3:) The confusion comes from this: a glob has certain fields: SCALAR, ARRAY, HASH, GLOB (not really a field...), etc. This does not imply that there is a separate data type for each, that it can point to. It's just pure coincidence that perl happens to have scalar, array, hash, and code as the four most important data types, and these are the four most well-known elements of a glob too.

Let's discuss this more (but I might be wrong, as I don't know perl internals as much as some other monks here, so correct me please).

It is clear, that the four most-well known elements of a glob are distinct data types: *foo{SCALAR} is a reference to a scalar, *foo{ARRAY} is a ref to an array, *foo{HASH} is a ref to a hash, and *foo{CODE} is a ref to a code. If $x is a ref to a scalar for exmaple, you can not make it become a ref to an array without changing $x itself.

On the other hand, *FOO{GLOB} (which is really the same as *FOO) is really a reference to a scalar, and you can see it is because of this:

$x = \$y; $y = *_; print $x; $y = 5; print $x;
[download]

GLOB(0x813bda0)
SCALAR(0x813bda0)
[download]

(Update: minor reformatting of the last few paragraphs.)

I've left out IO handles, FORMATs, (Update 4:) Regexps, and packages from this discussion because I don't really know them well. IO handles is a fifth kind of data type I think, but I'm not sure.

(A bit off-topic:) Also note that I these four (or more) types are not the types an expression can have. That's something very different. The value of a perl expression is a scalar, a list, or nothing depending on its run-time context (which depends on the callers of the expression, but not the expression itself). It's just plain wrong that scalar and list contexts are sometimes associated with scalar and array data types. For example, the scalar glob element *FOO{SCALAR} is magically linked with $FOO, which returns the content of the scalar field of *FOO in scalar context, or a list of a single element (the contents of the scalar field) in list context. Things are not so simple with *FOO{ARRAY} which has four constructs linked to it: @FOO, $#FOO, $FOO{EXPR}, @FOO{EXPR}, \@FOO which more or less return values related to *FOO{ARRAY}. Note that \@FOO is not just the \ operator applied to @FOO. The \ operator normally returns a list of the references of the elements of the list it gets as argument (ie a list of scalar refs), or a single scalar ref in scalar context. (Most of these constructs can also be used in lvalue context, such as \$FOO{EXPR}, push @CODE, EXPR, $FOO{EXPR} = EXPR etc, which makes things even more complicated.) What shows that these are indeed associated with the*FOO{ARRAY} array reference is that you can put any array reference instead of FOO in any of the above construcs (but you have to add a brace unless the expression yielding the reference starts with $). The same goes with hashes and subroutines, the special expressions associated with them are %FOO, $FOO{EXPR}, @FOO{EXPR}, and \%FOO with hashes; and FOO(EXPR), &FOO(EXPR), &FOO, \&FOO, FOO EXPR (if declared), FOO INDIROB EXPR (if prototyped so), FOO {STMTS} EXPR (if prototyped so); (I might have missed some).

Update: I forgot to answer this one:

LVALUE has a better case for utlity than REF, because this is how you find out if something *is* an lvalue. (I think? Do you know another way?) For references, you already have the ref builtin itself. See my comment to

No. Actually, most (or all?) scalar references are lvalues. For exmple $x = \$y; is an lvalue reference as you can say $$x = 5;.

(Update 3: trying to add some more context to the second and third paragraph to make it cleaner.)