On 06/08/2009 23:56, Peter Gammie wrote:
On 07/08/2009, at 12:00 AM, Simon Marlow wrote:
On 06/08/2009 14:20, Peter Gammie wrote:
On 06/08/2009, at 10:59 PM, Simon Marlow wrote:
On 06/08/2009 13:49, Thomas Davie wrote:
On 6 Aug 2009, at 14:37, Nils Anders Danielsson wrote:
On 2009-08-06 11:08, Malcolm Wallace wrote:
yet, because of the definition of $!, this applies the
constructor to
its arguments right-to-left instead of the intuitive left-to-right.
I do not think that there is a bug: x `seq` y `seq` e has the same
denotation as y `seq` x `seq` e.
Not if one considers the "kind" of bottom one receives:
undefined `seq` error "it exploded" `seq` e will print
"Prelude.undefined"
while
error "it exploded" `seq` undefined `seq` e will print "Error: it
exploded"
There's only one kind of bottom in Haskell 98. And even with the
imprecise exceptions extension, both expressions still have the same
denotation - they denote the same set of exceptions, one of which is
non-deterministically picked when the program is run.
If the FFI Addendum is considered part of Haskell 98, then we have
unsafePerformIO, and so an appeal to denotational equivalence is not
sufficient. When grafting a pure interface onto a notionally-pure
library (specifically a BDD library), I often used seq to get these
effects buried in "pure" values under control.
That sounds like a very dangerous use of seq and unsafePerformIO to me!
How so? Take this code:
newtype BDD = BDD (ForeignPtr Int)
exists :: Group BDD -> BDD -> BDD
exists group bdd = bdd `seq` unsafePerformIO $
withGroup group $ \ gid ->
do bdd_assoc bdd_manager gid
withBDD bdd ({#call unsafe bdd_exists#} bdd_manager) >>= addBDDfinalizer
Without the seq, a recursive use of a quantifier will screw up the
effect of bdd_assoc. How is this unsafe?
IMHO I'm using seq in the standard way, to shuffle the data dependencies
to get better (correct) operational behaviour.
I grant that it is dodgy in a concurrent setting, but the library itself
is not thread safe.
If, as I understand it, you are relying on the fact that seq's first
argument is evaluted before its second, then you really want pseq rather
than seq.
This is the sense in which I mean it's a dangerous use of seq and
unsafePerformIO - because the compiler is within its rights to evaluate
the second argument to seq "first".
In GHC we provide a way to do what you want (pseq), I'm just not
convinced it should be the required behaviour of seq.
Cheers,
Simon
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
