On 2014-11-12 at 12:57:16 +0100, Sean Leather wrote: [...]
I'd love to be able to depend on the fromIntegral RULEs instead of adding toBoundedIntegral RULEs, but I found cases where the fromIntegral RULEs were not firing. So I thought I would make GHC's job easier by including all of the RULEs. If there's a better way, I'm all for it.
I didn't realise fromIntegral suffered from the same issue. I'm afraid I don't know a better way with the current infrastructure either :-/
Moreover, you limit yourself to 'Bounded' types (which is why I resorted `Bits` rather than 'Bounded' for 'intCastMaybe' after noticing that I couldn't convert from (half)unbounded 'Integer' or 'Natural' to/from bounded types).
I'm not sure how the function is “limited” by using Bounded.
I meant limited in that it excludes converting to/from integral types such as 'Integer'.
Aren't they just different constraints? If your type doesn't have a Bits instance but does have a Bounded, then you would use the function that required Bounded. How often this happens in practice, I don't know.
IMHO, It happens quite a lot actually that you go via 'Integer' to make sure you don't silently incur arithemtic overflows. I personally tend to do that in code where I'm interested in using checked conversions like `toBoundedIntegral` in the first place.
Anyway, I don't see a reason why we couldn't have both toBoundedIntegral and intCastMaybe. Or, if you prefer intCastMaybe, let's use that instead. I'm not strongly tied to toBoundedIntegral, but it would be nice to see something in base because more people will see it.
I guess that if we add toBoundedIntegral, I'd like to see toBitsIntegral as well. (IOW, I'd be +0.5 for adding both functions up to bikeshed-isomorphism)
So I'm on the fence about 'toBoundedIntegral', as for one I want such a facility for conversion, but OTOH, I'm not happy with the limitations 'toBoundedIntegral' exhibits. I'd like to see a more general solution.
Just to be clear, I understand one limitation you've presented: the RULEs. You mentioned limiting to Bounded, but I'm not clear how that's a limitation compared to using Bits, as you do.
What do you mean by a more general solution? IMHO, this is simply a “better” fromIntegral, and fromIntegral is used a lot for bounded types. I don't see how having toBoundedIntegral or intCastMaybe precludes or diminishes other developments, esp. ones that deal with more type information. These functions are useful as they are now for many types.
As stated above, if it's on the table to add both, I'm +0.5. As you say, they are indeed useful given the current infrastructure (which only gives us Integral/Enum/Num/Bounded/Bits to work with at this point) I'm curious though, if it's supposed to be a better 'fromIntegral', why did you chose the name 'toBoundedIntegral' rather than 'fromIntegralBounded' which has more resemblance to 'fromIntegral' (and has a closer tab-complete-distance to it as well)? Cheers, hvr PS: I've s/intCaseMaybe/intCastMaybe/ in the quoted parts to avoid confusion