Re: [Haskell-cafe] Re: Efficient or predictable Ord for Typeable

[Lennart Augustsson]

George Russell wrote:
Simon Peyton-Jones wrote:
The trouble is that *any* function can now deliver unpredictable
results.  Can I rely on the fact that
foo :: Int - Int
will always give the same answer given the same input.  Not any more.

Yes, I see what you mean.
I think the strongest argument here is that it's like a more benign
version of unsafePerformIO, whose existence also threatens foo's
predictability.

I suggest you implement
   hashTypeable :: Typeable - IO Int32
And/or
mkHashTypeable :: IO (Typeable - Int32)
-- Lennart
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Efficient or predictable Ord for Typeable

[George Russell]

(me)
I suggest you implement
   hashTypeable :: Typeable - IO Int32

Lennart wrote (snipped)
And/or
mkHashTypeable :: IO (Typeable - Int32)

Although this is OK, a general hash function might well need
to return IO HashKey.
A while back, before Data.Unique, I implemented a Unique module
with interface:
   newUnique :: IO Unique
   uniqCompare :: Unique - Unique - IO Ordering
The values returned by uniqCompare are guaranteed to be consistent.
This implementation (which was not meant terribly seriously) was
unusual because it did not use unsafePerformIO or any other global
state, though it did need MVars and access to the current thread
identifier (if in a concurrent world).  The ordering was constructed
dynamically as you called uniqCompare.  The source is here:
   
http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg01109/Unique.hs
Converting the function to be of type
   getUniqCompare :: IO (Unique - Unique - Ordering)
would be impossible.  I suspect there may be other cases where you
dynamically construct a hash function.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe