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.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.