Attriel wrote: > Well, in general I think it would be good to have some mechanism for > determining the type of the data rather than the type of a > representation of the contained value.
Why? One of the nice things about Perl is that coercian takes care of these kind of things so that you don't have to worry about them. If you pass a string containing a sequence of digit characters when an integer is expected, Perl just works it out. > If I have "0", it's possible I might at some point (this having been > user input perhaps) have some reason to care whether it was an integer > or a string. How would the user distinguish when providing the input? The Perl 5 ways of reading input -- whether from the keyboard, a file, or a form on a webpage -- yield strings. Even if the user thinks she has provided an integer, the program gets a string (but that doesn't matter). For validation purposes things like Regexp::Common are currently handy for determining whether provided input can be treated as a number or an integer or whatever. Perl 6's ability to use its own grammar rules should make those kinds of things considerably easier. > I know I hate the fact that, in almost every lang I use, adding the > strings "014" and "231" requires me to do ' "" + string1 + "" + > string2 ' Fortunately Perl isn't one of those languages. In general you need for either variables or operators to be typed. JavaScript has problems with untyped variables and addition/concatenation; PHP has problems with string/numeric comparisons. Many languages 'solve' this problem by ensuring all variables have types. Perl goes the other way and ensures operators are sufficiently typed, having C<+> and C<.>, and C<lt> and C<< < >>. Perl 5 fell down in having the bitwise operators behave differently with numbers and strings; Perl 6 fixes this by having different operators for each operation. So the type that data has previously been (albeit possibly only in the mind of the user who entered it) isn't particularly useful; if the data can be coerced to that type (or any other required type), then that is sufficient. > ... I imagine there might exist cases where the information is useful > ... I'm struggling to think of any -- if you come up with some please could you mail them so I can understand your viewpoint better. Needing to know about this kind of thing strikes me as most unPerlish. Smylers
