A UniqSupply has a single shared Int behind the scenes, so it's really no different. Simon Marlow may want to comment on your proposed solutions. Personally I think Option 1 is most attractive. Yes, the API changes, but in a decent way and one that may be useful for other things. Now I think of it, why can't 'install' do the workAroundGloblals call? Then clients would not need to. Maybe I'm not thinking straight Simon From: ghc-devs-bounces@haskell.org [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Nicolas Frisby Sent: 05 July 2013 18:14 To: ghc-devs@haskell.org Subject: use UniqSupply in FastString? Does it sound reasonable to change the FastString module to use a UniqSupply instead of using that Int for generating uniques? I've been trying to let a statically-linked compiler shares its FastString table with plugins. Status, background info, options here: http://hackage.haskell.org/trac/ghc/wiki/Plugins/ReinitializeGlobals (I got a little ahead of myself with Option 2...) Uniques for FastStrings are currently allocated linearly using a global Int variable. Because unsafePerformIO is used, it's difficult to keep the two global Ints in synch (one for the compiler, the other for the plugins). The danger is that the compiler and a plugin might allocate the same unique for distinct FastStrings - that'd break a major invariant. If we used UniqSupply, we'd avoid that danger, just about for free. I'm not sure how robust/speedy UniqSupply is though. Considering its widespread use, I figured it'd be good enough by a pretty wide margin; FastString *creation* seems relatively infrequent. Thanks for your input.