clearly, not be

I didn't say "clearly, not be", I said: "might not be".

I was quoting hippo, who said

... and many, many more are clearly not only numbers.

who replied to my saying constants that were hex or octal and started with a number (or 0x for hex) also fell into the category of being "only being a number", since 0x, *especially*, seems to have been created ONLY for hex (vs. a leading zero seems like a convention for octal).

I'm simply saying that if I have a string containing "0x41" and use it in addition, why shouldn't perl auto-numify it just like it does "65" in a string? Admittedly, treating "065" like octal now, could cause some incompatibility, but I would assert it already is confusing to people who know that octal constants start with a "0".

But lets ignore the explicit quoting of such -- simple read user input or read input from a file -- did the user type a number or input a string that could be a number? Say you have a loop:

while (<>) {
  chomp;
  printf "input as string=%s, as decimal=%d\n", $_, $_;
}'
# now user does input:
65
input as string=65, as decimal=65
0x41
Argument "0x41" isn't numeric in printf at -e line 5, <> line 2.
input as string=0x41, as decimal=0
"65"
Argument ""65"" isn't numeric in printf at -e line 5, <> line 3.
input as string="65", as decimal=0
[download]

So if the user inputs a quoted number, it doesn't numify (not saying it should), but if they input a naked number in decimal or hex, the decimal works, but the hex does not.

If I do the same in shell, the unquoted case is how I think perl *could* work, the string case is a bit surprising but useful. That's shell for you, don't throw an error when you could do something useful (unless the error is required by posix... ug).

> while read a; do
> printf "string=%s, as decimal=%d\n" $a $a
> done
65
string=65, as decimal=65
0x41
string=0x41, as decimal=65
"0" 
string="0", as decimal=48
"0x30"
string="0x30", as decimal=48
[download]

In the unquoted case, bash converts a numeric looking string to an internally representation of a number. In the quoted case, when printing "0" as a decimal, it prints the ordinal (c.f. ord) for the 1st character of the quoted string where as a quoted hex number yields the ordinal of the 1st char of the "chr" of the hex-value.

Ok, I am not holding up bash for an example of clear consistency, just that for the user-input (or values read from a file, in the unquoted case, it's possible to tell how to interpret the string based on context: a string context retains the literal, and a numeric constant tries a numeric conversion (numification?), which yields a 0 in the case of conversion failure.

If perl did this, where would it cause harm? If a user tries to use "0x6" as a numeric value now, perl fails to convert (it doesn't work/isn't a case of "working code". If perl switched to converting "0x6" to "6", it would only affect situations that previously failed with a warning -- i.e. it would create functionality where before there was error, non-functioning-code, or dysfunction.

I'm simply saying...

That after 22 years of Perl5, you've invented a requirement no else needs, and are completely impervious to reason.

My prediction: This won't change any time soon -- not this year nor next -- but you'll keep banging on about it for another week or two -- like you did about Unicode in code blocks -- until you find another windmill to tilt at.

I ignored your last post, then comes this one. Now you're added to my ignore list.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.