On Mon, Sep 09, 2013 at 07:59:28PM +0200, Chaddaï Fouché wrote:
In the following expression, the result is: Success (Just 11).
Success $ Just $ truncate (f * 100)
In the following expression, the result is: Success (Just 12)
let expanded = f * 100 ans = truncate expanded in trace (show expanded) $ Success $ Just $ ans
That made me think that "f * 100" had to be strictly evaluated before given to truncate for some reason, so I tried using seq to get the same effect, but that didn't work. Am I correct in assuming that laziness has something to do with this problem?
It would be a serious bug if that was true since lazyness shouldn't change the semantic of a program, except sometimes by allowing the program to terminate where the strict version wouldn't.
On the other hand I can't reproduce your bug, couldn't you provide more details (including GHC version and parsing code)
-- Jedaï
I put together a simple library and web app to demonstrate the behavior I'm seeing: git clone git@bitbucket.org:bryanvick/truncate.git The README has simple instructions to view the behavior in a repl or in a web app. The Lib.hs file is where the parsing code is. I swear I saw different behaviour between separate cabal sandboxes while I was testing this. Sometimes the parsing would work as expected, sometimes it wouldn't. That made me think that maybe different versions of dependencies are being installed for different runs. I'll start paying attention to "cabal sandbox hc-pkg" to see if this is the case.