On Mon, Sep 09, 2013 at 08:28:48PM -0400, Brandon Allbery wrote:
> On Mon, Sep 9, 2013 at 8:03 PM, Bryan Vicknair <bryanvick@gmail.com> wrote:
>
> > Whatever the behavior of truncate is, given the same input it should give
> > the
> > same output.
> >
>
> An ideal, but unlikely when floating point is involved; optimization can
> result in altered evaluation order or removal (or even addition in some
> cases) of load/stores which can modify the internal representation. Note
> that ghci is completely unoptimized.

Thanks everyone for the help.  I think I'll write my own parsing code instead
of using reads and truncate.  I really don't like floats.  The whole reason
this parsing code exists is so that the DB can store a simple integer instead
of a float, but I still need to show the value as a float to the users.

This is scary though.  This is the first leak I've found in the referential
transparency abstraction in Haskell (besides unsafePerformIO).  And the problem
is, if I don't have referential transparency for 100% of pure functions, then I
have to be suspicious of every one.  I can use some heuristics to narrow down
the suspects, such as questioning floating point functions first, but I just
had my bubble burst nonetheless.

Is there any resource that compiles all the potential exceptions to the Haskell
abstract machine?

_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners