4 ms·
the lack of explicitness about casting exact types (Integer, Rational) to inexact types (Int, Float) has led to many bugs and confusions for me Matches my limi
by owl57 7y ago
the lack of explicitness about casting exact types (Integer, Rational) to inexact types (Int, Float) has led to many bugs and confusions for me
Matches my limited experience with Haskell. You get some bad bugs that you don't get in Python because all the stuff like len([1,2,3]) gives int (≡ Haskell's Integer), and 0.1 + 0.2 means the same thing every time. But I'm really interested in the opposite direction: bad bugs you get in Python but not in Haskell.
- jolmg 7y agoWell, like I had responded to that comment back then, casting is very explicit in Haskell, but I think they were confusing casting with type inference. Most of the time, 0.1 + 0.2 is the same thing every time, but you do have the option of it being different types, depending on what you need.
- tome 7y agoCan you explain how that leads to a bug?
- owl57 7y agoimport qualified Data.ByteString as B import qualified Data.ByteString.Char8 as C main = do let x = 100 print (x * x) let y:_ = B.unpack (C.pack "foo") --let z = x * y return () If we uncomment that line, the output of this program changes from 10000 to 16. Yes, I learned this by triggering similar action "in the past" accidentally. Don't remember details, but that program also involved ByteStrings. The convention of explicitly type-annotating top-level declarations is there for a reason: it limits the scope of damage.