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