A module signature can contain data types, and the units can contain the concrete data types. This allows e.g. a common interface for all string packages: https://github.com/haskell-backpack/backpack-str As you can see (particularly here: https://github.com/haskell-backpack/backpack-str/blob/master/str-sig/Str.hsi...), one can let the *type* vary in a way that typeclasses do not allow. On 07/18/2018 10:19 PM, Clinton Mead wrote:
Hi All
I read though Edward Z. Yang's blog post http://blog.ezyang.com/2016/10/try-backpack-ghc-backpack/ about Backpack but I can't understand what it does above and beyond classes and instances.
It seems to me we could just replace a "signature" with a "class" and a "unit" with an "instance" and achieve the same thing.
Of course there are issues with orphans instances if we don't own either the class or the associated data, but it would seem to me that "orphan units" are no less problematic than "orphan instances".
Edward Kmett's unpacked-containers https://www.reddit.com/r/haskell/comments/8a5w1n/new_package_unpackedcontain... gets some speed improvements using Backpack, but is Backpack just optimisation thing, or are there ways you can organise code with Backpack that you couldn't do without just classes and instances? For example, does Backpack solve the issue of packages requiring huge dependency lists to implement instances that most of their users will not use?
Thanks, Clinton
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.