Let’s imagine a world in which the string problem was solved by Backpack. What would it look like?
All the important libraries (base, aeson…) would be indefinite: they would depend on a module signature for strings, instead of using a concrete type.
The decision about which kind of string to use would take place at executables and test suites, by making them depend on the corresponding implementation package.
Is this realistic?
I don’t see large swathes of the ecosystem choosing to become indefinite. A more conservative and backwards-compatible approach could involve the “multiple public libraries” feature of Cabal (do those work on Hackage yet?) For a certain package, the main library would be the traditional concrete form; the indefinite form could be exposed as a sublibrary for those interested. To avoid duplication, the concrete form should be implemented in terms of the indefinite one (this would require the use of reexported-modules:
, which don’t play well with Haddocks IIRC.)
Defining an executable or test suite would often require an annoying extra dependency: even if your Main.hs
doesn’t handle strings directly, some indefinite dependency might, so you’d need to throw in some string implementation.
There’s the issue of how to handle versioning of module signatures. They’re a bit weird in that respect, because merely adding a function to them is a breaking change (because some implementation packages might suddenly become incomplete!)
So far, few actual libraries in Hackage have chosen to use Backpack to provide flexibility in string representation. I expected wider adoption. But in retrospect it’s understandable why it didn’t caught on: fiddling with compilation units involves a lot of ceremony, and module signatures are very different from the typeclass-based polymorphism Haskellers are familiar with.