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)
> 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 10:30 AM, Pedro Vasconcelos wrote:
On Wed, 20 Jul 2011 12:48:48 -0300
Thiago Negri 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 ne
On Wed, 20 Jul 2011 12:48:48 -0300
Thiago Negri 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
> arguments: [1..] =
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, Jul 20, 2011 at 23:53, Richard O'Keefe 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 breaking is with
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
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, whi
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".
L
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. Pat
David Barbour wrote:
> On Wed, Jul 20, 2011 at 10:40 AM, Chris Smith 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 that the garb
On Wed, Jul 20, 2011 at 13:40, Chris Smith 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 and
> inform
> 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 10:40 AM, Chris Smith 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 equality testing
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 13:22, Chris Smith 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 negatives, and y
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.
C
On Wed, Jul 20, 2011 at 10:48 AM, Thiago Negri 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 it's value is r
Quoting Thiago Negri :
> 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 everything is
> Haskel
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 th
Carl Howells wrote:
> On Tue, Jul 19, 2011 at 11:14 PM, yi huang wrote:
> > 2011/7/20 Eugene Kirpichov
> >>
> >> 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 goo
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
On
On Tue, Jul 19, 2011 at 11:14 PM, yi huang wrote:
> 2011/7/20 Eugene Kirpichov
>
>> 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.
>
Any number of
> 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,
On Tue, Jul 19, 2011 at 11:14 PM, yi huang wrote:
> 2011/7/20 Eugene Kirpichov
>>
>> 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.
False positives a
2011/7/20 Eugene Kirpichov
> 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" написал(а):
>
> > Hi,
> >
> >
reallyUnsafePointerEq#, and it really is as unsafe as it sounds :)
20.07.2011, в 7:51, "Nikhil A. Patil" написал(а):
> 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 che
On Tue, Jul 19, 2011 at 23:51, Nikhil A. Patil wrote:
> 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.
>
Let's p
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
29 matches
Mail list logo
