I'm personally weakly +1 on this.
I've needed and duplicated the functionality before, and its just tricky
enough to cross the Fairbairn threshold, and baroque enough to be centrally
maintained with all the rewrite RULES to make it fast.
I don't have a strong preference over just doing this / doing both this and
fromBitsIntegral.
-Edward
On Wed, Nov 12, 2014 at 8:36 AM, Sean Leather
On Wed, Nov 12, 2014 at 3:04 PM, Herbert Valerio Riedel wrote:
On 2014-11-12 at 12:57:16 +0100, Sean Leather wrote:
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'.
I see, that's true. As far as I'm concerned, toInteger works well for the ->Integer direction and toBoundedIntegral works well for the Integer-> direction. My primary use for toBoundedIntegral is for larger-to-smaller integral type conversions.
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.
I meant that I don't know how often having a Bounded instance and no Bits instance (or vice versa) happens in practice. In other words, I'm not sure which is more likely needed – a function with a Bounded constraint or a function with a Bits constraint – or if it really matters much at all.
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)
Works for me. I'd be happy with either one or both.
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)
Exactly.
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)?
Good bike-shedding question. In short, minimum ambiguity. To me, 'fromIntegralBounded' can be read as if the argument and not the result is Bounded. I felt 'toBoundedIntegral' used the convenient “adjective-ness” of 'Bounded' and 'Integral' to unambiguously describe the result.
PS: I've s/intCaseMaybe/intCastMaybe/ in the quoted parts to avoid
confusion
Thanks. My fingers have a tendency to type 'case' instead of 'cast'. Too much pattern-matching and too little conversion? Who knows. ;)
Regards, Sean
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries