Unclear dependency (instance Hashable Unique) makes reactive-banana build fail about vault HOT 6 CLOSED

Apparently, the underlying problem is that vault exports two slightly different APIs, one that includes the Hashable instance (when the UseGHC flag is set) and one that does not include the instance (when the UseGHC flag is not set). Reactive-banana assumes that the instance is always there, and hence fails for some configurations of vault, which is clearly a defect on my part.

One thing I don't understand is why the vault package was being without hashable in the first place. My intention was that the UseGHC flag is not optional when compiling with GHC. (The reason for that is that the default Data.Unique doesn't work correctly in GHCi, so I had to supply my own Data.Unique.Really.) It seems that cabal decides this on a whim, namely sets the flag to false when the dependencies cannot be satisfied with the currently installed packages.

(The whole UseGHC flag story is actually only because I wanted to compile reactive-banana to JavaScript using the haste compiler and the hashable packages used too many GHC tricks. I got things to compile at some point, but unfortunately, it seems that the JS output is subtly incorrect and reactive-banana doesn't work. Then again, the library is using unsafePerformIO for observable sharing and thus tests the boundaries of legal Haskell, so small errors in the compiler tend to crash the banana party big time.)

from vault.

Your comment about cabal is exactly my point: it seems cabal ignores that I am indeed using GHC and silently unsets the flag.
I think you are not alone with this: many packages on hackage create subtle conditional dependencies, and it is increasingly difficult to manually resolve package dependencies as I did (the text-dependency of hashable is just another example).
The clean thing here would be to create a single API, but I fully understand why you went the other way.
If you want to keep the 2-API package, I suggest that vault issue a big warning (using CPP) during the build to let the user know that the API is incomplete (in case UseGHC is unset). Then again, is there any chance for reactive-banana to build (with the reduced vault API) when using a Haskell compiler different from GHC? It depends on hashable directly and via vault right now, and probably uses unsafePerformIO "the GHC way".

from vault.

Ok, I changed reactive-banana to not make use of the Hashable instance for Unique. Thanks again for the report, @jberthold !

Concerning the vault package, it's probably a good idea to remove the UseGHC flag altogether. I'm hesitant to do it right now, though, because the vault-0.3.0.0 branch still needs some polish. I'll just leave this open until the next release if nobody minds.

from vault.

IMO, you shouldn't keep the UseGHC stuff around for Haste; if the GHC version doesn't work then that's a problem with Haste that I should be fixing (at least as long as you're not using black pointer arithmethic primop magic); working around it just gives me an incentive to be lazy. :)

from vault.

Well, it can be useful for other compilers like EHC as well, for which a JavaScript backend exists as well.

Concerning Haste, there is still issue 25 whose resolution would be very beneficial for me. ;-)

from vault.

Removed the 'UseGHC' flag entirely and added a dependency on 'hashable'. Haste has hopefully advanced enough for this to be viable.

from vault.