Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Apply, Witherable and Align instances #14

Open
tysonzero opened this issue Oct 14, 2018 · 6 comments
Open

Add Apply, Witherable and Align instances #14

tysonzero opened this issue Oct 14, 2018 · 6 comments

Comments

@tysonzero
Copy link

I have found the above to be extremely useful for generically working with various types of Maps. Between them you basically get filtering, unioning and intersecting in a convenient and generic way.

I realize this means depending on witherable, these and semigroupoids. But alas the current Haskell orphan instances situation means that there isn't really a good way around that.

@Mikolaj
Copy link
Owner

Mikolaj commented Jan 2, 2019

Hi! I'm your new maintainer. :)

Is it possible to define the instance outside enummapset? Do we expose enough internals? Are the definitions very long? I think I'd rather have another package that depends on enummapset and adds a lot of instances. Some people would not depend on that new package anyway, but just copy-paste only the instances they need, but that's fine. OTOH, they can't copy-paste enummapset easily, so I'd keep its deps small. What do you think?

@tysonzero
Copy link
Author

It is possible but I mean that has all the usual downsides of orphan instances. I suppose we could also ask the maintainers of the classes to depend on enummapset like they depend on containers already.

@Mikolaj
Copy link
Owner

Mikolaj commented Jan 2, 2019

A long shot, but surely try talking with maintainers of these packages and perhaps link back to this issue. Talking and being aware of each other is always a good idea. Regarding orphans, it's unfortunate, but currently that's a common thing with many other packages.

@tysonzero
Copy link
Author

I will create those issues now. Perhaps the long term solution is to convince people that EnumMap belongs in containers (as well as or instead of IntMap).

We really do need a proper long term language-level solution for orphans though.

@Mikolaj
Copy link
Owner

Mikolaj commented Jan 2, 2019

Agreed on all accounts. Thanks for that. Perhaps separate IntMap and EnumMap in containers make most sense, because EnumMap needs some base operations to inline to, and IntMap fits this role perfectly. Also if some people have some particular use case where they use honest, arithmetic Ints all over the place, they can underscore this rare situation by using IntMap and also they don't need the notation and compilation overhead of EnumMap Int.

@Mikolaj
Copy link
Owner

Mikolaj commented Jan 6, 2019

Slightly related: I noticed http://hackage.haskell.org/package/regex-tdfa defines its own EnumMap and `EnumSet'. If that was part of containers, they'd surely use the version from base instead of rolling their own.

Edit: ChrisKuklewicz/regex-tdfa#19

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants