On Wed, Nov 24, 2004 at 02:40:52PM +0000, Ben Rudiak-Gould wrote:
John Meacham wrote:
randomIO [...] Data.Unique [...] Atom.hs [...] caching
These are all great examples of cases where having per-process state makes sense.
But they can all be implemented with George Russell's library plus safe (pure) uses of unsafePerformIO. I hope his library or something like it will become a part of the standard distribution, and there's nothing wrong with having (pure) functions in the standard library which can't be implemented in Haskell, so I don't think these examples are sufficient on their own to justify a language extension. I'd still like to see an example of something that can be done with top-level <- but is inconvenient or impossible with George Russell's library.
George Russell's library is precicly an invalid use of unsafePerformIO. Internally, it does the invalid unsafePerformIO (newIORef) trick which is exactly the problem we are trying to solve. hiding it in a module doesn't make it go away. I am not positive, but it also would also add the overhead of a finitemap lookup across all global variables for every look up. which doesn't really meet efficiency requirements. a global counter should only need a single peek poke to a constant location, not some data structure lookup. I spent a lot of time hand crafting a fast unboxed hash function for strings because that was a bottleneck in my Atom implementation, it would be a shame if all gains were overshadowed by what should be a very fast constant-time operation to begin with.
This is not a minor performance gain. in ginsu it dropped the memory usage from > 100megs to 10megs. I would call that vital. when it used 100megs it was not a usable program.
Not that I think implementing Atom with a global hashtable is a bad idea, but I'm curious where in that range the memory usage would be if you defined
type Atom = PackedString toAtom = packString fromAtom = unpackPS
Not very much. I had already writen my own utf-8 encoded PackedString with only moderate gain. due to the nature of the program a lot of the same unpredictable string is read in over the network, being able to unify their memory usage without too much hassle is a big big win. John -- John Meacham - ⑆repetae.net⑆john⑈