I found a bug in the conversion from int to string. I also need to realize how to do tests for the lib.

Bug solved. The remainders where being generated reversed. I just had to reverse that list and everything is now working nice.

I also added tests, some of them compared with results from Python.

Result of nixpkgs-review pr 258834 run on x86_64-linux 1

These char -> int attribute sets should not be exposed in the interface, it's an implementation detail.

There's also already lib.toHexString and lib.toBaseDigits which this PR should unify with.

I also think it should be called lib.intRepresentations or so, "bit" would only match for binary.

Whoa, I didn't know about toBaseDigits. It's almost the same thing I am trying to do here lol.

These char -> int attribute sets should not be exposed in the interface, it's an implementation detail.

There's also already lib.toHexString and lib.toBaseDigits which this PR should unify with.

I also think it should be called lib.intRepresentations or so, "bit" would only match for binary.

I changed the implementation of toHexString to use intRepresentations and added the possibility for one to only pass the name of the base instead of the mapping.

I also refactored the mapping logic to be a list and when parsing it also builds a lookup table that makes that attrset so lookups are faster and it's harder to provide invalid inputs.

I am not sure if I should keep that lookup table function there or move somewhere else tho.

Hmm still not very happy with the interface, how about something like

• formatBinary :: Int -> String: Formats a number as binary
• formatOctal :: Int -> String: Formats a number as octal
• formatHex :: Int -> String: Formats a number as hexadecimal

Also parseBinary, parseOctal, etc.

But I guess much more importantly, can you show why we need all of these? We shouldn't add functions without use cases to lib.

Hmm still not very happy with the interface, how about something like

• formatBinary :: Int -> String: Formats a number as binary
• formatOctal :: Int -> String: Formats a number as octal
• formatHex :: Int -> String: Formats a number as hexadecimal

Also parseBinary, parseOctal, etc.

But I guess much more importantly, can you show why we need all of these? We shouldn't add functions without use cases to lib.

Initially, parsing a hex hash to decompose in values to use with the port allocator RFC implementation. That way we can generate valid ports that are less likely to have collisions.

That hinges on the RFC/PR being accepted/merged, and from what I could tell it's not close to that, so I don't think we can use that as justification. And this would only be a justification for parseHex, not any of the other functions.

That hinges on the RFC/PR being accepted/merged, and from what I could tell it's not close to that

Then let's keep it as a proof-of-concept.

And this would only be a justification for parseHex, not any of the other functions.

Completeness.

Completeness.

I'm very much against merging 5 functions without any use cases just because of "completeness". Interfaces without any use cases are but a maintenance burden. We can always easily add more functions later if the use cases do happen to arise.

Completeness.

I'm very much against merging 5 functions without any use cases just because of "completeness". Interfaces without any use cases are but a maintenance burden. We can always easily add more functions later if the use cases do happen to arise.

At first I only wanted to add a hex parser to int. That's what I need actually, but as the logic keeps the same I added support for arbitrary mappings. BTW maybe it's best to remove the case normalization (all uppercase for example) and that mapping aliases and then add a fromHEXString to follow the same but inverse signature as toHEXString.

Did a rebase

But I guess much more importantly, can you show why we need all of these? We shouldn't add functions without use cases to lib.

When working with ip addresses and subnets having functions to convert to and from binary and hex to decimal is incredibly useful. Like writing a function to check if a ip is part of a subnet basically requires converting it and it's netmask to binary and throwing and logic on it, or when doing any calculations with ipv6 where the entire ip is represented as hex values.

@Janik-Haag Sounds like a good use case to me!