use UniqSupply in FastString?

Simon Marlow marlowsd at
Sat Jul 6 08:48:36 CEST 2013

I haven't been following this in detail, but I think you're encountering 
the same problem we had with various top-level IORefs in the base 
package.  The solution we have there is grotesque but it works.  Take a 
look at libraries/base/GHC/Conc/Signal.hs, search for
getOrSetGHCConcSignalSignalHandlerStore.  There is some corresponding 
RTS gunk to help with this in rts/Globals.c.

We can't make FastString use UniqSupply - it must use unsafePerformIO, 
since the whole point is to hide the side effects behind a nice pure API.


On 06/07/13 00:03, Simon Peyton-Jones wrote:
> 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 at
> [mailto:ghc-devs-bounces at] *On Behalf Of *Nicolas Frisby
> *Sent:* 05 July 2013 18:14
> *To:* ghc-devs at
> *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:
> (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.

More information about the ghc-devs mailing list