> There are some differences between Hugs & GHC's memo table > implementations, and some shortcomings in the GHC implementation.
Actually, I'd say the shortcomings are in the Hugs implementation. > The main difference is that Hugs uses not just pointer equality but > also real equality when the keys in the hash table are Int or Char; > GHC doesn't do this. In GHC, making a memo table with Int or Char > keys really doesn't work too well - our memo table implementation is > geared towards using pointer equality for dynamic objects. On the > other hand, GHC's memo tables support garbage collection of hash > table entries (as you well know :-), whereas Hugs's memo tables will > grow for ever. Part of the reason Hugs' memo tables grow forever is that because it uses real equality for Int and Char keys, it can't discard any of those entries. John Hughes' paper on Lazy Memo Functions is pretty clear about why you should use pointer equality. The other part of the reason is that the Memo implementation was somewhat sloppy. It needs GC support to avoid a space leak but that wasn't added when the Memo stuff was added. > The equality difference explains the behaviour you're seeing: when > you memo-copy the tree, GHC doesn't find any hits because the labels > at each node are Ints. It should be easy enough to construct your > own memo table implementation that is specialised to Int, though, > and use this instead of the generic Memo.memo whenever you need a > memo table with Int keys. But if you use Ints as keys, you should expect to have space leaks because the entries can't be discarded until the memo tables are discarded. -- Alastair Reid [EMAIL PROTECTED] http://www.cs.utah.edu/~reid/ _______________________________________________ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
