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.hsig#L237), 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 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 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.