Repository navigation
Ord for PortNnumber behaves strangely #346
Description
Activity
PortNumberholds anWord16in network-byteoder.
So, if you are using a little endian CPU, this happens.
Since I'm not the original designer forPortNumber, I don't know what is the correct behavior.There are a few questions here:
-
Should
PortNumberhave anOrdinstance?
Being able to predicate on port ranges seems like a reasonable use case. Even generating port ranges withrandomR. As well I might want aSetof them,Hashablecan provide that, but not ranges. So I'd say yes. -
What is the most natural instance?
We typically think of these artifacts as integer-like. Thinking in endians is an implementation artifact of a given environment. Using an integer based order seems more natural. -
Is there a "correct" instance?
Is the byte order instance more correct? Should the given environment influence how this order behaves. To me that sounds surprising. I don't know if it is more correct or just a choice. -
Is changing the instance a breaking change?
I'm sure someone is using this instance for something. I'd call this a breaking change.
-
Hmm yes that would work, you'll need both
EqandOrd. But looking at the code, it seems we convert back to Int order for almost every operation usingportNumberToInt, which makes me wonder if there's any point in maintainingPortNumberin network byte order.It seems to me the only place this actually matters is the
Storableinstance. I'm more inclined to say we should drop all the current instances, useGeneralizedNewtypeDerivingto derive them, then they're internally consistent, and change theStorableinstance to convert back and forth between network byte order.That would make the instances simpler I think.
Is there a "correct" instance?
Is the byte order instance more correct? Should the given environment influence how this order behaves. To me that sounds surprising. I don't know if it is more correct or just a choice.I don't know about correct, but it's inconsistent with the other instances such as
Num. We don't perform for instance theadditionon the network byte-ordered version, so why would we do comparisons?OK. I will work according to @Mistuke's approach.
Thanks y'all! Sounds like a good solution to me!
I don't know if this is something you all want to solve but there's some really weird behavior that happens due to eagerly converting for endiannes at construction of
PortNumber(I assume that's what's going on)I discovered this when attempting to validate a port range
(PortNumber, PortNumber)such that the first is <= the second. I expect one solution would be to covert back to integer for Ord. Another would be to not pre-convert the word into network byte order until you need it internally (perhaps even creating an internal newtype to convert between the two), but that sounds very tricky to get right and a much larger diff.