Publish (parts of) concat on Hackage?

[sellout]

I'm curious if @conal is interested in this at all and, if so, what are any issues standing in the way of it.

For our purposes, we only care about concat-classes and concat-examples being published (although this implies all their deps are published).

There are two things I'd like to see change before concat-examples is published, though:

1. its tests shouldn't require human interaction (all the graphviz windows need to be closed for the test to complete) and
2. it shouldn't depend on concat-plugin (moving the tests to concat-plugin would solve both of these, I suppose).

I'm happy to do the work to get this to happen if there's interest.

[freckletonj]

I would love to see this too, and I'd be happy to help!

I've been re-engineering my own category library basically for both learning's sake, but also, I feel like this library has been a little buggy for me. I'll just mention some friction points I've had that I think would improve it's use as a library:

• Cosmetically: there are a lot of (now) superfluous comments, dead code blocks, #if 0 ..., #if 1 ..., and the Experiment modules
• Similarly, the module/directory layout could be improved. It's tough to find things, even if I know they exist.
• Some naming has changed between Conal's papers and this library that makes things tough to find. Eg "ProductCat" vs "Cartesian".
• Is the class hierarchy settled? It seems perhaps overly complex. @sellout I like your library haskerwaul, and think it's an elegantly accomplished point in the design space. I think concat would look nice to have a hierarchy nearer that, but I would also consider, for a mainstream library, that endusers may not need the full granularity of abstractions like you've included (eg Magma may be too fine grained).
• Should Products be hard-coded as (,) or an (associated?) type family? This would also solve the Cartesian category class that use biproducts, I think they're called (where both sums and products are the tuple type (a, b)).
• The plugin seems like an overly complex addition whose needs have apparently infected the whole library. I say infected because, I never really could get tests or examples to work, let alone my own attempts. I'm sure it does work, I may just not be advanced enough of a user, but, I think that does make me a candidate enduser to consider if releasing this as a library. I think an example of this is AltCat. Was that split out for plugin reasons?
• The CPP stuff is neat for keeping it DRY. It's a bit messy too though, but, maybe if it was laid out nicer?
• I always thought the constraint entailment stuff was a bit over my head. QuantifiedConstraints seems to make more sense, and I noticed there's been some talk about that https://github.com/conal/concat/issues/60. It looks like Conal later solved this like so.
• I once tried to make concat-classes Haddock-compatible, but in the end struggled with something, I forget now what it was, but if it's released, this is something we'll need to solve.
• When you say to keep concat-examples, do you mean to make bonafide GAD modules for instance? That'd be awesome. Would they be opt-in dependencies? Like concat-ad, concat-fft, concat-circuit etc? Actually, early in a project's life, it'd be much easier I'd think to just maintain all that within the concat library and break them out down the road if needed. But, I'm no library maintainer, and maybe that'd be too harsh on endusers.

@sellout , I'm also curious what you see are the tradeoffs between putting effort in concat vs your haskerwaul?

[sellout]

Cosmetically: there are a lot of (now) superfluous comments, dead code blocks, #if 0 ..., #if 1 ..., and the Experiment modules

At least for the Experimental modules, one thing I've done, but never tried to push upstream was to turn those into separate branches, with more meaningful names than A, B, C. I'm not sure the fork that had those branches still exists, but I'd be happy to re-do that work if maintaining those variants is helpful (it might instead be helpful to just explain in some comments why those experiments were ultimately unsuccessful). The branches also keep changes on master from breaking the experimental modules.

Is the class hierarchy settled? It seems perhaps overly complex. @sellout I like your library haskerwaul, and think it's an elegantly accomplished point in the design space. I think concat would look nice to have a hierarchy nearer that, but I would also consider, for a mainstream library, that endusers may not need the full granularity of abstractions like you've included (eg Magma may be too fine grained).

One of the other benefits of concat's structure is that it works very well for Haskellers who are less familiar with category theory. It tends to use familiar Haskell names (Num, Constraint, etc.) that map very directly through the plugin vs more categorical names (ring, subcategory) where the connection between -> input and k output can often be less obvious.

In my hierarchy, something like Magma is necessary because the class graph is so, uh, graph-y, that you need a common ancestor to say "all these properties apply to the same operation", but like you say, that's too fine-grained for most users. concat-classes does a better job, I think, of targeting that mainstream familiarity.

The plugin seems like an overly complex addition whose needs have apparently infected the whole library. I say infected because, I never really could get tests or examples to work, let alone my own attempts. I'm sure it does work, I may just not be advanced enough of a user, but, I think that does make me a candidate enduser to consider if releasing this as a library. I think an example of this is AltCat. Was that split out for plugin reasons?

Section 10.3 of http://conal.net/papers/compiling-to-categories/compiling-to-categories.pdf explains the reason for AltCat, and yes, it does seem like something that may fit better in concat-plugin than concat-classes.

When you say to keep concat-examples, do you mean to make bonafide GAD modules for instance? That'd be awesome. Would they be opt-in dependencies? Like concat-ad, concat-fft, concat-circuit etc? Actually, early in a project's life, it'd be much easier I'd think to just maintain all that within the concat library and break them out down the road if needed. But, I'm no library maintainer, and maybe that'd be too harsh on endusers.

I think splitting the concat-examples categories into separate packages would be nice, but for now I'd be happy to just have the package published as-is. We use those categories for various purposes at work (e.g., testing our use of concat-classes).

@sellout , I'm also curious what you see are the tradeoffs between putting effort in concat vs your haskerwaul?

I've tried to capture that in https://github.com/sellout/haskerwaul#comparisons. I still see Haskerwaul as just an exploration and I don't expect all of these category libraries to thrive, but I don't yet know which ones will. There are plenty of questions I haven't yet seen satisfying solutions for, and Haskerwaul isn't (yet) in a place where it could be used in concat-plugin in place of concat-classes. It's more flexible in some ways, but then runs up against walls in other places.

[freckletonj]

it might instead be helpful to just explain in some comments why those experiments were ultimately unsuccessful

this would be hugely valuable, at least to me!

various purposes at work

... time for a tech blog? :D

or now I'd be happy to just have the package published as-is ... we use those categories for ... eg testing

That makes sense to me. I wonder though if it needs to even be packaged, or could just live in tests?

What ever you decide, lmk how I can help!

[conal]

Thanks for the interest and suggestions. I'm way down a rabbit hole, so I've given myself a reminder to join the conversation.