Huge dependencies due to Void

[ivanperez-keera]

The Void instance of HasTrie has the following transitive dependencies:

• void (57K)
• text (4.7MB)
• hashable (124K)
• nats (71K)
• unordered-containers (537K)
• semigroups (1.1MB)

I'm wondering whether that instance shouldn't belong elsewhere. Does it add real value?

Context: We'd like to make Yampa depend on vector-space, but bringing along so many deps to save us 15 lines of code seems like an overkill. Yampa is being used to develop Android games, so size is pretty important.

[conal]

I really don't know what to think about this one. To split off this Void instance, I think I'd need to create a new package.

[ivanperez-keera]

:( (I wouldn't want you to go through that trouble, I'd rather maintain a private fork for Android development purposes then.)

If it were controlled by an optional flag that we could disable, would that be too much hassle? Or too ugly, for that matter?

It would mean adding the flag to the cabal file (flag def + (compiler option -DVOID + build-depends) controlled by that flag), and changing the haskell file (CPP pragma, plus imports and instance enclosed in #ifdef).

[conal]

Thanks for the flag suggestion. I'm open to that possibility, but I'd like to explore some alternatives. The Void type is quite fundamental, algebraically, being the ring zero (identity for sum and annihilator for product). Rather than awkwardly avoiding Void for any number of libraries for which it makes sense, maybe we can make it cheaper to use. If we cannot, then I suspect that there is a language and/or infrastructure issue to solve. Given that it's as fundamental as (), maybe it belongs in the prelude.

[sboosali]

void is now in base: https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Void.html

[conal]

@sboosali Oh, wow. I'm delighted to hear that Void is in base now. Thanks for the alert. Do you (or @ivanperez-keera) know the necessary incantations to conditionally use the void package or not in both the Haskell source and the .cabal? I've forgotten. I'm still using GHC 7.8.2 (pending release of 7.10.3), so I can test with that version if someone else can test with 7.10.

[sboosali]

let me know if this builds https://github.com/sboosali/MemoTrie/commit/28c647163b98b66592e32dae29afcd107b60defd

note:

• in the cabal file, my edit assumes that GHC releases and base versions are synchronized (via the impl flag), but I don't know if that's true.
• I added EmptyCase to avoid absurd.
• I insulated the needed symbol in a separate (not exposed) module.

however, this is my first time dealing with different compiler versions. I spent the past half hour reading through:

https://hackage.haskell.org/package/lens-4.13/src/lens.cabal and
https://www.haskell.org/cabal/users-guide/developing-packages.html#configurations and https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/guide-to-ghc-extensions/basic-syntax-extensions#packageimports

and that's all I know. someone else might also want to take a look at this too.

[sboosali]

(and, your package is amazing! it blew my mind when I saw how sums became products and products became functions)

[conal]

@sboosali Thanks for investigating! Your branch does indeed compile fine for me in GHC 7.8.2. I attached a question in your commit.