Functions => NP

[reactormonk]

I've created this piece of code with the help of lyxia: https://gist.github.com/reactormonk/c4dd738b4f23281b6ab35b53c8661c91 - maybe it's useful somewhere? Should I open a PR?

[matchwood]

Ah nice, I put together curry/uncurry for NP here: https://github.com/matchwood/acid-world/blob/develop/src/Acid/Core/Utils.hs#L173 , but I stole a type family from Vinyl to do it. I think it would be worth adding both curry and uncurry natively, as they are quite useful!

[kosmikus]

I've certainly used variants of these before. The reason I haven't added them was that it didn't seem directly connected to generic programming. But I'm open to adding something like this.

[edsko]

I have to admit I often use generics-sop simply for it's awesome products :)

[matchwood]

Yeah this library has loads of useful applications beyond generics - I ended up relying almost exclusively on it for handling heterogenous structures after experimenting with hlist, vinyl and others.

I'm wondering if a standalone package, giving definitions and interfaces for heterogenous lists and extensible records, would be worth having? A lot of it would just be type synonyms and specialised renamed functions, but it would provide an accessible entry point.

[adamConnerSax]

I agree with this! Both directly—the library is useful for heterogeneous structures—and also such a subset would partially satisfy another old issue, having a TH-free subset of the library. A version without the generic piece would be TH free and then one could include the instances one needed.

[kosmikus]

Ok. In principle, I'm happy to:

• break up the data structures and the actual generic programming parts of the library,
• add in extra functions that are useful.

I'm not sure how much time I will have doing this, though. The latter is more likely to happen than the former. To address this particular issue, I'll try to add some curry/uncurry functionality.

[matchwood]

I might have time to help out with this - much of the work should be fairly straightforward I think.

Would it be worth having three packages, like:

sop-base - definition of data structures and classes for working with them: NP, HTraverse etc
generics-sop - depends on sop-base and re-exports everything so the API remains the same.
sop-extra - curry/uncurry, convenience definitions and functions for heterogenous lists, extensible records and anything else...

sop-extra (or a better name!) could then be positioned as a coherent and accessible solution for heterogenous structures.

[kosmikus]

I agree about sop-base and generics-sop.

I'm less certain whether having sop-extra is worth it. As long as there are no extra dependencies incurred, I think it's probably better to expose as much functionality as possible directly from the two other packages.

If you want to help, that's great! If you want to have a chat with me before you start, we can arrange something next week.

[kosmikus]

See also #61 for the request to have a TH-free library subset.

[matchwood]

Great, I've opened a new issue for the split #75.

On the subject of curry/uncurry specifically, uncurry is fairly straightforward, but curry requires some finessing. If you have any code floating around for that then I am happy to try to adapt it into a library appropriate form.

[kosmikus]

I've been looking a bit into how I'd like to do curry/uncurry. In order to get optimal inference, I came up with the solution here: https://gist.github.com/kosmikus/482be398be4397d6a8742347f02c9c2a

Unfortunately, this is suffering from a GHC bug (https://ghc.haskell.org/trac/ghc/ticket/15772), so I'm not sure how much the extra type inference is worth in practice, as it seems to be fragile.

So the question is whether to include a simpler and more straight-forward version, or whether to include the "full" version and hope that the GHC bug is fixed at some point (and not overly harmful in the meantime).

Another possible problem is that we have to find proper names for all the constraints involved, although I am leaning towards just renaming C to CurryUncurry, and leaving the rest as it is.