Simon Marlow

I started at this for a while and I don't think I understand all the ramifications. You can certainly do very strange things with `dataFetchEquiv`. What are the properties under...

Yeah I suspect this would be quite difficult. Haxl computations don't execute in a nicely scoped way like IO does, you would have to mask/unmask when suspending and resuming fragments...

Taking a glance over this, it is slightly intrusive and touches some performance-critical bits (e.g. `DataCache.lookup`). We'll need to be careful it doesn't impact performance.

@jkomyno in principle I have no objection to including a bounded cache of some kind, but it needs to have zero (or close to zero) overhead.

I can understand the need to limit the cache size in certain use cases. However, as soon as we stop caching everything, we lose the nice replayability property that Haxl...

Unsafe foreign imports which can block for unpredictable amounts of time cause performance problems that only emerge when scaling to multiple cores, because they delay the GC sync. This is...

One other option: - Default to safe for all the dangerous imports - Provide a compile-time cabal flag to switch to unsafe - Upload `unix-unsafe` to Hackage which is the...

The point of `unix-unsafe` is that it lets you express it as a dependency, and it can co-exist with `unix`. I don't think there would be a problem with mixing...

@hvr the flag means that the difference between the `unix` and `unix-unsafe` packages is a single line in the `unix.cabal` file, so it's easy to automatically generate `unix-unsafe` and to...

Surely just a `default: False` turns into `default: True`? Anyway if it's two lines I wouldn't call it a problem.