Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re^9: why are hex values not numbers?

by BrowserUk (Patriarch)
on Sep 27, 2016 at 17:31 UTC ( #1172769=note: print w/replies, xml ) Need Help??


in reply to Re^8: why are hex values not numbers?
in thread why are hex values not numbers?

clearly, not be

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


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.

Replies are listed 'Best First'.
Re^10: why are hex values not numbers?
by perl-diddler (Chaplain) on Sep 27, 2016 at 20:03 UTC
    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
    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
    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.
        That after 22 years of Perl5, you've invented a requirement no else needs, and are completely impervious to reason.
        Impervious to reason? What reason has anyone given to the question of why a hex constant (e.g. 0xa0) shouldn't be able to be converted in any place perl auto-converts a decimal number?

        Requirement? If I was adding a restriction or forcing someone to use the feature, it would be a requirement -- but right now, it's something that doesn't work -- so no one is using it. If it was adopted, then still no one would be required to use it. In no way can it be considered a "requirement" that people would need to follow.

        Extending privileges or options, to people, is never something that is "required".

        Requirements are things forced upon people. In contrast, options are things people have a choice to do or not.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1172769]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (5)
As of 2023-01-30 07:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?