For the following expression, I would consider a True result a false positive:
let x = x :: Int in x == x
Dean
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Wed, 20 Jul 2011 12:48:48 -0300
Thiago Negri evoh...@gmail.com wrote:
Is it possible to implement (==) that first check these thunks before
evaluating it? (Considering both arguments has pure types).
E.g.,
Equivalent thunks, evaluates to True, does not need to evaluate its
On 07/21/2011 10:30 AM, Pedro Vasconcelos wrote:
On Wed, 20 Jul 2011 12:48:48 -0300
Thiago Negrievoh...@gmail.com wrote:
Is it possible to implement (==) that first check these thunks before
evaluating it? (Considering both arguments has pure types).
E.g.,
Equivalent thunks, evaluates to
Any examples for hangups of 'smartEq' are greatly appreciated, I couldn't
produce any so far.
Following sequences will hang smartEq. They are both infinite and aperiodic.
smartEq (fromList primes) (fromList primes)
smartEq (fromList pidigits) (fromList pidigits)
On 07/21/2011 02:15 PM, Alexey Khudyakov wrote:
Any examples for hangups of 'smartEq' are greatly appreciated, I couldn't
produce any so far.
Following sequences will hang smartEq. They are both infinite and aperiodic.
smartEq (fromList primes) (fromList primes)
smartEq (fromList pidigits)
2011/7/20 Eugene Kirpichov ekirpic...@gmail.com
reallyUnsafePointerEq#, and it really is as unsafe as it sounds :)
Why is it so unsafe? i can't find any documentation on it.
I think always compare pointer first is a good optimization.
20.07.2011, в 7:51, Nikhil A. Patil
On Tue, Jul 19, 2011 at 11:14 PM, yi huang yi.codepla...@gmail.com wrote:
2011/7/20 Eugene Kirpichov ekirpic...@gmail.com
reallyUnsafePointerEq#, and it really is as unsafe as it sounds :)
Why is it so unsafe? i can't find any documentation on it.
I think always compare pointer first is a
Is there any way of getting the following code to immediately return
True without performing the element-by-element comparison? Essentially
this boils down to checking whether pointers are equal before
comparing the contents.
main = print $ f == f
where f = [1..10^9]
Nikhil,
As
On Tue, Jul 19, 2011 at 11:14 PM, yi huang yi.codepla...@gmail.com wrote:
2011/7/20 Eugene Kirpichov ekirpic...@gmail.com
reallyUnsafePointerEq#, and it really is as unsafe as it sounds :)
Why is it so unsafe? i can't find any documentation on it.
I think always compare pointer first is a
On Jul 19, 2011, at 11:34 PM, Levent Erkok wrote:
import System.Mem.StableName
areEqual :: Eq a = a - a - IO Bool
areEqual x y = do
sx - hashStableName `fmap` (x `seq` makeStableName x)
sy - hashStableName `fmap` (y `seq` makeStableName y)
return $ (sx == sy) || x == y
One
Carl Howells wrote:
On Tue, Jul 19, 2011 at 11:14 PM, yi huang yi.codepla...@gmail.com wrote:
2011/7/20 Eugene Kirpichov ekirpic...@gmail.com
reallyUnsafePointerEq#, and it really is as unsafe as it sounds :)
Why is it so unsafe? i can't find any documentation on it.
I think always
Hello all,
I'm a newbie at Haskell and I was not aware of this problem.
So, equality comparison can run into an infinite-loop?
My current knowledge of the language tells me that everything is
Haskell is a thunk until it's value is really needed.
Is it possible to implement (==) that first check
Quoting Thiago Negri evoh...@gmail.com:
Hello all,
I'm a newbie at Haskell and I was not aware of this problem.
So, equality comparison can run into an infinite-loop?
Yes, comparing infinite lists is a non-terminating computation.
My current knowledge of the language tells me that
On Wed, Jul 20, 2011 at 10:48 AM, Thiago Negri evoh...@gmail.com wrote:
Hello all,
I'm a newbie at Haskell and I was not aware of this problem.
So, equality comparison can run into an infinite-loop?
My current knowledge of the language tells me that everything is
Haskell is a thunk until
On Tue, 2011-07-19 at 23:33 -0700, Carl Howells wrote:
False positives and false negatives are both possible, depending on GC
timing. Don't use it, unless you know why it can result in both false
positives and false negatives, and you know why neither of those are
bad for your use case.
Can
On Wed, Jul 20, 2011 at 13:22, Chris Smith cdsm...@gmail.com wrote:
On Tue, 2011-07-19 at 23:33 -0700, Carl Howells wrote:
False positives and false negatives are both possible, depending on GC
timing. Don't use it, unless you know why it can result in both false
positives and false
On Wed, 2011-07-20 at 13:32 -0400, Brandon Allbery wrote:
I think it's more correct to say that the compiler is free to do
things that would lead to false positives if it knows that it's safe
to do so (and purity means it can find more of those cases, and more
of them *will* be safe) — but
On Wed, Jul 20, 2011 at 10:40 AM, Chris Smith cdsm...@gmail.com wrote:
I have looked up crowbar in a number of dictionaries of slang and
informal usage... and still have no idea what you just said. Can you
reword it?
Crowbars offer 'leverage'.
The point, I think, is that if pointer
have not updated the first pointer yet. But if that's the case, and
it's executing arbitrary user code that may refer to that memory, then
the garbage collector contains race conditions!
Not necessarily, if the garbage collection and the move happened
between taking the pointers of the two
On Wed, Jul 20, 2011 at 13:40, Chris Smith cdsm...@gmail.com wrote:
On Wed, 2011-07-20 at 13:32 -0400, Brandon Allbery wrote:
of them *will* be safe) — but there is no way for it to crowbar
pointer equality tests in that case.
I have looked up crowbar in a number of dictionaries of slang
David Barbour wrote:
On Wed, Jul 20, 2011 at 10:40 AM, Chris Smith cdsm...@gmail.com wrote:
The point, I think, is that if pointer equality testing really does what
it says, then there shouldn't *be* any correct implementation in which
false positives are possible. It seems the claim is
I would have thought that the compiler, as a matter of optimisation,
could insert a check to see if (==) is comparing an object with itself.
The only way I can see this breaking is with perverse instances of Eq
that would return False for f == f.
Paul.
On 07/20/2011 04:51 AM, Nikhil A.
On 7/20/11 5:08 PM, Paul Johnson wrote:
I would have thought that the compiler, as a matter of optimisation,
could insert a check to see if (==) is comparing an object with itself.
The only way I can see this breaking is with perverse instances of Eq
that would return False for f == f.
Like
On 7/20/11 1:22 PM, Chris Smith wrote:
If the latter, then it seems this would be a
pretty serious garbage collector bug, and that it would be impossible
that such a bug wouldn't also break other code that doesn't use pointer
equality at all. After all, we've got a running user thread, which
On 21/07/2011, at 9:08 AM, Paul Johnson wrote:
I would have thought that the compiler, as a matter of optimisation, could
insert a check to see if (==) is comparing an object with itself. The only
way I can see this breaking is with perverse instances of Eq that would
return False for f
On Wed, Jul 20, 2011 at 23:53, Richard O'Keefe o...@cs.otago.ac.nz wrote:
On 21/07/2011, at 9:08 AM, Paul Johnson wrote:
I would have thought that the compiler, as a matter of optimisation,
could insert a check to see if (==) is comparing an object with itself. The
only way I can see this
Hi,
Is there any way of getting the following code to immediately return
True without performing the element-by-element comparison? Essentially
this boils down to checking whether pointers are equal before
comparing the contents.
main = print $ f == f
where f = [1..10^9]
Thanks!!
nikhil
On Tue, Jul 19, 2011 at 23:51, Nikhil A. Patil patil.nik...@gmail.comwrote:
Is there any way of getting the following code to immediately return
True without performing the element-by-element comparison? Essentially
this boils down to checking whether pointers are equal before
comparing the
reallyUnsafePointerEq#, and it really is as unsafe as it sounds :)
20.07.2011, в 7:51, Nikhil A. Patil patil.nik...@gmail.com написал(а):
Hi,
Is there any way of getting the following code to immediately return
True without performing the element-by-element comparison? Essentially
this
29 matches
Mail list logo
