Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type-safe from/to helper functions #31

Open
ppetr opened this issue Jul 2, 2016 · 2 comments
Open

Type-safe from/to helper functions #31

ppetr opened this issue Jul 2, 2016 · 2 comments

Comments

@ppetr
Copy link

ppetr commented Jul 2, 2016

Currently various from.../to... functions work with just [Int]. I'd suggest to:

  1. Return appropriate data types, that is Word8 for to/fromIPv4 and to/fromIPv6b, and Word16 for to/fromIPv6.
  2. Add variants for from/toIPv6 and from/toIPv4 that take/return 4-tuples and 8-tuples instead of lists. This is safer, and it's still possible to efficiently work with such tuples by wrapping them for example with NTup4 / NTup8 which provide Traversable, Applicative etc.

I'll be happy to contribute, if we agree on this.

@kazu-yamamoto
Copy link
Owner

So, do you mean that these function should be polymorphic?
Anyway, please show your code to me.

@ppetr
Copy link
Author

ppetr commented Jul 9, 2016

My current code for the network package is here: haskell/network#210
(sorry for the confusion before). At the end I thought that it'd be better suited for the network package directly, but perhaps both packages could benefit from such functions.

No, I had no polymorphism on my mind. IPv4 addresses are defined to be 4 8-byte unsigned numbers and IPv6 as 8 16-byte unsigned numbers, so my suggestion is to add functions that convert to precisely such a representation. And to use tuples instead of lists, as conversions from list are partial functions (are well defined only if the argument has the correct length), while conversions from tuples are total functions. Making them polymorphic might make their use easier, but might cause errors if they're used on an inappropriate integral instance, so I'd rather keep them with the exact correct type,.although I'm open to discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants