Hi Vanessa Sorry, I still can't understand what backpack is doing beyond classes and instances. map-classes http://hackage.haskell.org/package/map-classes-0.1.0.0/docs/Control-Class-Im... gives a common interface for key-value maps (i.e. arrays, maps, hashmaps, etc), just using classes and interfaces. Indeed this seems to be what classes were designed to do, for example, the IArray class gives a common interface over int index immutable arrays. I'm missing something obviously. How can the type "vary" in a way type classes does not allow? Couldn't the code you referenced just be a three parameter type class? Thanks, Clinton On Thu, Jul 19, 2018 at 1:44 PM, Vanessa McHale wrote:

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 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.

_______________________________________________ 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.

Hi Silvio That makes a lot of sense thanks for the reply! Thanks, Clinton On Thu, Jul 19, 2018 at 4:20 PM, Silvio Frischknecht < silvio.frischi@gmail.com> wrote:

Hi

It seems similar to the modules system of ML. As I understand it, the main difference to Haskell type classes is that you have to specify instances explicitly in in this system. This means you get more control at the expense of more code.

Have a look at this example on stackoverflow.

https://stackoverflow.com/a/36927542/1117884

Cheers

Silvio

_______________________________________________ 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.