Backpack vs plain old classes and instances

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Backpack vs plain old classes and instances

Clinton Mead
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.
Reply | Threaded
Open this post in threaded view
|

Re: Backpack vs plain old classes and instances

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

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

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Backpack vs plain old classes and instances

Clinton Mead
Hi Vanessa

Sorry, I still can't understand what backpack is doing beyond classes and instances.

map-classes 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 <[hidden email]> 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 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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Backpack vs plain old classes and instances

Silvio Frischknecht
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.
Reply | Threaded
Open this post in threaded view
|

Re: Backpack vs plain old classes and instances

Clinton Mead
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 <[hidden email]> 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.


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