http://qs321.pair.com?node_id=1173104


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

This thread gave no valid reason. Or are you claiming that my asking for rational, logical support in the form of reasoning or reasons, that such is a child-like behavior. This is a not a nursery school. Isn't it supposed to be a place where we can have technological discussions? It seems asking for references or valid & consistent reasons valid in computer science.

Requirement? You claim I don't know what the word means, yet like a petulant child, you say "And I'm not gonna tell ya." You can't define your terms in a technical forum? Then don't claim to know them or claim to be capable of judging others' use of the them.

There is a good reason to do it: compatibility with any other language -- in places where other languages allow decimal input (usually at the source level, though also at runtime in interpreted languages), they also allow hex, and, usually octal at the minimum. Perl stands alone in not being able to convert a hex constant in a string when it CAN convert a decimal in the same place.

Potential for silently getting a '0' value for bad-source code? What more do you want? Show me anyplace in CPAN where the person put "0x" in front of a string of hex digits, and they didn't mean that they wanted a hex string.

You are talking about a error in the first place and second, it's a very unlikely error, one I doubt you can find an example for, but if you needed such pickiness, you could have 'lint' complain about such cases. You shouldn't use it as the only reason to block a feature that makes the language easier for others.

This is why perl is dying a slow death -- because no one will support any common sense changes that make things *easier* for new people coming to the language. Instead, the things that do get approved are pinning tails on vars, that, of any method of allowing forced-typing, is the most verbose and most cryptic looking. So much so, that I know no other mainstream language that uses such a syntax (may be out there, but I've not seen such). It won't help outsiders understand perl -- just create more confusion.

Replies are listed 'Best First'.
Re^15: why are hex values not numbers? (octal)
by tye (Sage) on Oct 02, 2016 at 05:16 UTC
    This thread gave no valid reason.

    Well, most of the thread didn't even try to give a reason. But I think Re^2: why are hex values not numbers? got it right.

    I recall finding a bug in C code that misinterpreted IP addresses padded to look nice: 

    216.211.126.174
216.057.063.004

    [download]

    by interpreting octets with leading zeros as being in octal.

    Perl decided to require you to be explicit if you want to interpret a leading zero as indicating octal when interpreting a string. oct() is how to indicate that you want the leading zero to impact the base when interpreting a string as a number.

    I concur with the choice to have "010" == 10 and "010" != 010. And I can see how it could seem more consistent to have the interpretation of 0x and 0b fall along the same lines.

    But stepping away from that consistency, I agree with you that it would be good to transition Perl so that it becomes possible for "0x10" == 0x10 (and that such eventually becomes the default). And I would like to see similar changes so we get to where "1_000" == 1_000.

    Beyond just a foolish consistency, it could also be argued that when asking a user for a numeric value, you should not assume that the user is a programmer. So you should treat "012" as "12" because that is what a non-programmer would mean. And you could extend that argument to other number formats that are expected of programmers but not others, like "0x1A4". But I disagree with that conclusion. "012" is a valid way to write 12. "0x12" is not a valid way to write 0.

    - tye        

[reply]
[d/l]
[reply]

        I had this thought before :)

        now perl gives warning 

        Argument "0x41" isn't numeric in printf

        [download]

        Very clean, things we know are numbers and can unambiguously identify as numbers, we treat as numbers, all other stuff we warn about

        But if definition of numeric was expanded to include more ambiguous num formats, then perl would need a new warning

        treating "0x41" as numeric , might be wrong thing to do, silence with 
+"no warnings q/extranumeric/;"

        [download]

        I'm confused why perl-diddler hasn't posted use extranumeric; yet :D

[reply]
[d/l]
[select]
      rewritten to reduce confusion.
[reply]
        what was "rewritten to reduce confusion"?
[reply]
      Um... If you are going to give a reason, I already ceded octal earlier in this discussion, for compatibility reasons. I limited my suggestion to constants beginning with "0x".

      As for 0xabcdef being a color code, that confusion already exists now, since color codes are, often, not in quotes. So the problem of "confusion" already exists.

      So I already excluded octal and someone came up with color codes in hex, which are already oft unquoted, so no increase in confusion w/that example.

      So back to the simple case of showing problems where allowing an auto-convert of 0x12 to 18, in a numeric context (where today, it would generate an error).

      Part of the problem in finding an example where it would be a problem is you'd have to present buggy code as the example. Code that only runs with a warning and generates '0' as a binary value when used in a numeric context. That's why detractors can't find an example: it would be an example of non-working code.

      Now does anyone get the point? The only way someone can accidently use "0x123456" as a binary value today...um...is they can't! They get a warning and the constant "0x123457" evaluates as binary zero. There can be no confusion in current code, because trying to decode a hex constant in a string returns a zero.

      As for future code. Maybe allowing hex constants anywhere decimal constants are, as in almost any other language, won't be so confusing to "just perl programmers", since programmers in other languages don't get so easily confused -- why would anyone protest that perl programmers would?

[reply]
        I already ceded octal: So, now it's only hex-like strings you want to make a special case of. The ideas wearing a bit thin isn't. someone came up with color codes in hex, which are already oft unquoted,: It doesn't have to be quotes -- its in a string. It's only you wants to be able to treat that ambiguous string as a number.

        You're like a dog with a bone tied to its tail, chasing around in circles refusing to let go! Fatuous.

[reply]
        A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Seekers of Perl Wisdom