>We're not thinking like in C where every variable `should' be prefixed with
>it's type, like p_var for a pointer to a variable or t_var for defining the
>type for var. In perl I just LOVE the way $, @, % and & unambiguously defines
>the type of the var. I just miss a prefix for formats (which will be dropped
>anyway) and IO.
[Semi-tangentially, but not wanting to sift out and unravel the threads
this could be sent to...]
As you've observed, but as many seem to forget, Perl already *has*
a strong type system. It's just not what Pascal programmers are
used to; this need not be construed a bug. It's what (many) natural
speakers (of Western languages) are most used to. That doesn't
mean it's automatically wrong, nor that Perl should be changed to
accomodate less inspired thinkers. Perl's type system fits our
brains a good bit better than compiler cruft does. Be not too quick
to dismiss it.
Perl's type system is more in the natural language sense of nouns
($ and @ for singular and plural inflections, respeectively) and
verbs (the functions). A hash, by representing an association, is
more the genitive or possessive sense. Or, you might think of it
as a list of duals, where one of the duality is more handlable than
the other. But we've lost our dual inflections for natural pairs
(one here hears Larry mumbles about oxen and Pudge joins him for
Classical Greek), so normally they're just ordered pairs in most
parlance.
The thing people need to remember when they think of the funny
characters as specifying a "type" of thing is that this is not a
"type" in the most common compsci sense.
$ just one atomic whatzitz
@ an ordered set of atomic whatzitzes
% an unordered lookupable set of atomic whatzitzes
& one atomic but executable whatzitz, which upon invocation
takes and returns (that is, both inputs and outputs)
an ordered set of atomic whatzitzes
The point is that "whatzitz" is really anything that's atomic. You
don't talk about a "numeric whatzitz", a "single character whatzitz",
a "fixed-length string" or "fixed-length number", whatzitz, a
"boolean" whatzitz, a "time of day" whatzitz, nor an "object"
whatziz.
That's why there is not nor should ever be a special "type" prefix
for filehandles, dirhandles, format names/handles, label names,
package names, objects/instances, etc. Each of these constitutes
one solitary thing, and thus unabiguously and obviously merits a $
prefix and none other. Anything else is a stark break from how the
language is put together.
--tom