In the current implementation of network, the ProtocolNumber type, defined in Network.Socket.Types, is given as
type ProtocolNumber = CInt
which means that it can only ever be displayed using the show method for Foreign.C.Types.CInt.
I initially was considering working on redefining it along the lines of
newtype ProtocolNumber = ProtocolNumber CInt
deriving (Eq, Ord, Enum, Real, Num, Integral)so that the implicit constraint Num a => a on numeric literals would be maintained, and so that it would be possible to define custom Read/Show instances that used pattern synonyms for commonly used protocols (e.g. TCP and UDP) for human-readability. (Along the lines of the pattern-synonym read/show work I implemented in #465 and #466)
Values that correspond to obsolete or extremely uncommon protocols could just be represented numerically, without any constructor syntax, as they are currently represented (and parsed) by default.
However, @vdukhovni pointed out that this would break the API for anyone using either variables or literals with explicit :: CInt signatures where ProtocolNumber values are expected, which could be either a trivial issue or a major problem depending on how common such usage is in the countless projects that have a dependency on network.
In any case, it seemed like enough of an obstacle that I wanted to consult with the project maintainers before I embark on a doomed mission that would break an indeterminate fraction of network-dependent code.
In the current implementation of network, the
ProtocolNumbertype, defined inNetwork.Socket.Types, is given aswhich means that it can only ever be displayed using the
showmethod forForeign.C.Types.CInt.I initially was considering working on redefining it along the lines of
so that the implicit constraint
Num a => aon numeric literals would be maintained, and so that it would be possible to define custom Read/Show instances that used pattern synonyms for commonly used protocols (e.g. TCP and UDP) for human-readability. (Along the lines of the pattern-synonym read/show work I implemented in #465 and #466)Values that correspond to obsolete or extremely uncommon protocols could just be represented numerically, without any constructor syntax, as they are currently represented (and parsed) by default.
However, @vdukhovni pointed out that this would break the API for anyone using either variables or literals with explicit
:: CIntsignatures whereProtocolNumbervalues are expected, which could be either a trivial issue or a major problem depending on how common such usage is in the countless projects that have a dependency on network.In any case, it seemed like enough of an obstacle that I wanted to consult with the project maintainers before I embark on a doomed mission that would break an indeterminate fraction of network-dependent code.