thanks again for your comments, any idea on how to implement "Equivalence"
for functions?
2012/6/26 Lorenzo Bolla <lbo...@gmail.com>
> In other words there is a difference between Identity and Equivalence.
> What you have implemented with StableName is an "Identity" (sometimes
> called "reference equality"), as opposed to an "Equivalence" (aka "value
> equality").
>
> In Python, for example:
>
> >>> x = {1:2}
> >>> y = {1:2}
> >>> x == y
> True
> >>> x is y
> False
>
> L.
>
>
> On Tue, Jun 26, 2012 at 3:42 PM, Lorenzo Bolla <lbo...@gmail.com> wrote:
>
>> I think about StableName like the "&" operator in C, that returns you the
>> memory address of a variable. It's not the same for many reasons, but by
>> analogy, if &x == &y then x == y, but &x != &y does not imply x != y.
>>
>> So, values that are semantically equal, may be stored in different memory
>> locations and have different StableNames.
>>
>> The fact that changing the order of the lines also changes the result of
>> the computation is obviously stated in the type signature of
>> makeStableName, which lives in the IO monad. On the other hand
>> hashStableNAme is a pure function.
>>
>> L.
>>
>>
>>
>> On Tue, Jun 26, 2012 at 3:26 PM, Ismael Figueroa Palet <
>> ifiguer...@gmail.com> wrote:
>>
>>>
>>>
>>> 2012/6/26 Lorenzo Bolla <lbo...@gmail.com>
>>>
>>>> The point I was making is that StableName might be what you want. You
>>>> are using it to check if two functions are the same by comparing their
>>>> "stablehash". But from StableName documentation:
>>>>
>>>> The reverse is not necessarily true: if two stable names are not
>>>>> equal, then the objects they name may still be equal.
>>>>
>>>>
>>>> The `eq` you implemented means this, I reckon: if `eq` returns True
>>>> then the 2 functions are equal, if `eq` returns False then you can't tell!
>>>>
>>>> Does it make sense?
>>>> L.
>>>>
>>>
>>> Yes it does make sense, and I'm wondering why the hash are equal in one
>>> case but are not equal on the other case (i.e. using let/where vs not using
>>> it) because I'd like it to behave the same in both situations
>>>
>>> Thanks again
>>>
>>>
>>>>
>>>>
>>>> On Tue, Jun 26, 2012 at 1:54 PM, Ismael Figueroa Palet <
>>>> ifiguer...@gmail.com> wrote:
>>>>
>>>>> Thanks Lorenzo, I'm cc'ing the list with your response also:
>>>>>
>>>>> As you point out, when you do some kind of "let-binding", using the
>>>>> where clause, or explicit let as in:
>>>>>
>>>>> main :: IO ()
>>>>> main = do
>>>>> let f1 = (successor :: Int -> State Int Int)
>>>>> let f2 = (successor :: Int -> Maybe Int)
>>>>> b2 <- eq f2 f2
>>>>> b1 <- eq f1 f1
>>>>> print (show b1 ++ " " ++ show b2)
>>>>>
>>>>> The behavior is as expected. I guess the binding triggers some
>>>>> internal optimization or gives more information to the type checker; but
>>>>> I'm still not clear why it is required to be done this way -- having to
>>>>> let-bind every function is kind of awkward.
>>>>>
>>>>> I know the details of StableNames are probably
>>>>> implementation-dependent, but I'm still wondering about how to detect /
>>>>> restrict this situation.
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> 2012/6/26 Lorenzo Bolla <lbo...@gmail.com>
>>>>>
>>>>>> From StableName docs:
>>>>>>
>>>>>>> The reverse is not necessarily true: if two stable names are not
>>>>>>> equal, then the objects they name may still be equal.
>>>>>>
>>>>>>
>>>>>> This version works as expected:
>>>>>>
>>>>>> import System.Mem.StableName
>>>>>> import Control.Monad.State
>>>>>>
>>>>>> eq :: a -> b -> IO Bool
>>>>>> eq a b = do
>>>>>> pa <- makeStableName a
>>>>>> pb <- makeStableName b
>>>>>> return (hashStableName pa == hashStableName pb)
>>>>>>
>>>>>> successor :: (Num a, Monad m) => a -> m a
>>>>>> successor n = return (n+1)
>>>>>>
>>>>>> -- main :: IO ()
>>>>>> -- main = do
>>>>>> -- b2 <- eq (successor :: Int -> State Int Int) (successor ::
>>>>>> Int -> State Int Int)
>>>>>> -- b1 <- eq (successor :: Int -> Maybe Int) (successor :: Int
>>>>>> -> Maybe Int)
>>>>>> -- print (show b1 ++ " " ++ show b2)
>>>>>>
>>>>>> main :: IO ()
>>>>>> main = do
>>>>>> b2 <- eq f2 f2
>>>>>> b1 <- eq f1 f1
>>>>>> print (show b1 ++ " " ++ show b2)
>>>>>> where f1 = (successor :: Int -> Maybe Int)
>>>>>> f2 = (successor :: Int -> State Int Int)
>>>>>>
>>>>>>
>>>>>>
>>>>>> hth,
>>>>>> L.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 26, 2012 at 1:15 PM, Ismael Figueroa Palet <
>>>>>> ifiguer...@gmail.com> wrote:
>>>>>>
>>>>>>> I'm using StableNames to have a notion of function equality, and I'm
>>>>>>> running into problems when using monadic functions.
>>>>>>>
>>>>>>> Consider the code below, file Test.hs
>>>>>>>
>>>>>>> import System.Mem.StableName
>>>>>>> import Control.Monad.State
>>>>>>>
>>>>>>> eq :: a -> b -> IO Bool
>>>>>>> eq a b = do
>>>>>>> pa <- makeStableName a
>>>>>>> pb <- makeStableName b
>>>>>>> return (hashStableName pa == hashStableName pb)
>>>>>>>
>>>>>>> successor :: (Num a, Monad m) => a -> m a
>>>>>>> successor n = return (n+1)
>>>>>>>
>>>>>>> main :: IO ()
>>>>>>> main = do
>>>>>>> b1 <- eq (successor :: Int -> Maybe Int) (successor :: Int ->
>>>>>>> Maybe Int)
>>>>>>> b2 <- eq (successor :: Int -> State Int Int) (successor ::
>>>>>>> Int -> State Int Int)
>>>>>>> print (show b1 ++ " " ++ show b2)
>>>>>>>
>>>>>>> Running the code into ghci the result is "False False". There is
>>>>>>> some old post saying that this is due to the dictionary-passing style
>>>>>>> for
>>>>>>> typeclasses, and compiling with optimizations improves the situation.
>>>>>>>
>>>>>>> Compiling with ghc --make -O Tests.hs and running the program, the
>>>>>>> result is "True True", which is what I expect.
>>>>>>> However, if I change main to be like the following:
>>>>>>>
>>>>>>> main :: IO ()
>>>>>>> main = do
>>>>>>> b2 <- eq (successor :: Int -> State Int Int) (successor ::
>>>>>>> Int -> State Int Int)
>>>>>>> b1 <- eq (successor :: Int -> Maybe Int) (successor :: Int ->
>>>>>>> Maybe Int)
>>>>>>> print (show b1 ++ " " ++ show b2)
>>>>>>>
>>>>>>> i.e. just changing the sequential order, and then compiling again
>>>>>>> with the same command, I get "True False", which is very confusing for
>>>>>>> me.
>>>>>>> Similar situations happens when using the state monad transformer,
>>>>>>> and manually built variations of it.
>>>>>>>
>>>>>>> It sounds the problem is with hidden closures created somewhere that
>>>>>>> do not point to the same memory locations, so StableNames yields false
>>>>>>> for
>>>>>>> that cases, but it is not clear to me under what circumstances this
>>>>>>> situation happens. Is there other way to get some approximation of
>>>>>>> function
>>>>>>> equality? or a way to "configure" the behavior of StableNames in
>>>>>>> presence
>>>>>>> of class constraints?
>>>>>>>
>>>>>>> I'm using the latests Haskell Platform on OS X Lion, btw.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> --
>>>>>>> Ismael
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Haskell-Cafe mailing list
>>>>>>> Haskell-Cafe@haskell.org
>>>>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ismael
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Ismael
>>>
>>>
>>
>
--
Ismael
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
