1.0 ?

[kosmikus]

I would like this library to reach version 1.0 ultimately, and I think it has been remarkably stable for a while now, despite the fact that it's still relatively young and that it uses a whole lot of different language extensions.

I'd like to collect opinions here as to what (if anything) everyone who's currently using the library would like to see before we label a release to be 1.0.

[phadej]

It would be nice to move to Identity, Const and Compose in base. That will mean dropping support for older GHCs; but that might be ok if 1.0 is not happening right away.

Another related issue, is that it would be nice to harmonise the naming so that Compose and Dict don't clash with Compose from base and Dict from constraints.

[kosmikus]

Perhaps we should even think about moving to Dict from Constraints?

I also agree that the move to the base functor types should happen eventually, with pattern synonyms for backwards compatibility and COMPLETE pragmas.

[phadej]

Dict in constraints is a bit different (:: Constraint -> *). where generics-sop's is :: (k -> Constraint) -> k -> *

[kosmikus]

@phadej Yes, I know. It'd be a bigger change. It might still be possible though.

[anka-213]

Regarding moving to using (what was) newly added features in base: I think the standard solution for this is to use base-compat, which has backported all the new stuff for older GHC and reexports the base versions if you have a recent GHC.

[kosmikus]

Yes, indeed. base-compat is a possible option. But regarding the basic functors, these are by now in base for so long that dropping compatibility with older GHCs is not really a concern anymore.

I'm still uncertain about the naming scheme in general.

I think if I would develop the library now, I would go for the long names in most places, and do:

NP -> Product
NS -> Sum
I -> Identity
K -> Const(ant)
SOP -> SumOfProducts
POP -> ProductOfProducts

However, some of these names would become quite long (ProductOfProducts).

Furthermore, I'm personally moving away from the overloaded variants of most of the generics-sop functions in favour of the specialised variants (better type inference, in particular in the presence of holes). However, these are currently all suffixed with

_NP
_NS
_SOP
_POP

and they would then also have to be renamed.

So all in all, I'm not sure if such a drastic change is worth it at this point, where existing code is using the short names.

Intermediate options are to only rename the base functors (still annoying), or to map the short base functors to the long ones via pattern synonyms (but this is potentially confusing, because error messages will possibly expand pattern synonyms).

So all in all, I'm simply undecided.

This, together with that there are no big looming changes in functionality right now, is the reason why there's still no 1.0.

Then again, there is ongoing work on a staged version of generics-sop, which will probably motivate a significant version bump, but might more likely become its own separate package.