Hungarian notation is any of a variety of standards for organizing a computer program by selecting a schema for naming your variables so that their type is readily available to someone familiar with the notation. Just as Python is a language that enforces the common practice of sane indentation by making it part of the language, Perl is a language that enforces a dialect of hungarian notation by making its variable decorations an intrinsic part of the language. What if, instead of cramming everything into "scalar" to the point where it loses its value as "a data type that magically converts between numeric and string, as needed," we undo the Great Perl5 Dilution and undecorate references. The Scalar and The Containers keep their decorations, and things that are neither numeric nor string values (references to reserved memory containing interpretable code, continuations, charm quarks, etcetera) get to stop dragging around a signifier which does not fit them. We are at the point where there are so many variable types that the dollar sign on their names has become a hollow formality. my dog $spot; #spot is a dog that looks like a scalar #spot holds neither numeric nor string data #why is spot burdened with the BASIC #string identifier? my dog spot; #after this declaration, it is clear that #spot is a dog. Should a programmer wish #or need to be even more specific about #these things, e could even say my dog dog_spot;#but it would be entirely up to em and #the language would not enforce it. So what I am suggesting is, Scalar as catch-all for unclassifiables that are neither strings nor numbers may have been a historic stopgap measure in perl 5 which was seen to be unworkable given the profusion of object types which became available in perl 6. An object of type "abstracted reference to a chair" is _NOT_ an object of type "numeric or string that magicly switches between as needed" This notation, my <type> <name> makes @ short for array my @chairs; # equivalent, define a container my ARRAY chairs; # keyed with wholes and so forth the name of the variable is chairs, its type is array, it is a container, it has the dozen methods described in the C<tie> documentation, and you can get to them the long way chairs.PUSH(map {woodworking} ARRAY(treestumps)); or take the shortcut push @chairs, map {woodworking} @treestumps; or even, if everything is declared nearby, so we don't need the decorations, which are now merely casts, push chairs, map {woodworking} treestumps; september's discussion, such as http://www.mail-archive.com/perl6-all@perl.org/msg03542.html never quite became a RFC (at least not one with "undecorated" in the title) at this point we start reducing the funny char load. The precious antipolymorphism of having @stuff and %stuff refer to two completely different sets of stuff can be retained, in which case the decorations must be used to disambiguate, or can be trashed, in which case decorations can be used or not used as the programmer sees fit, just as you can cast every occurance of every variable in a C program if you want and it will compile just the same as if you had merely declared them all exactly once. Thanks for listening, I think I did well on the statistics final, got two projects to do and then the semester is over.Thread Next