Use indexed-traversable #951
Conversation
|
I added more rules and now the benchmarks don't seem to have anything suspicious (my machine is incredibly noisy, I suspect some boosts are firing here and there) benchmark: foldsbenchmark: traversals |
|
LOL. Each "commit suggestion" triggers CI. Complete non-sense. (Yes, I noticed Add suggestion to batch after I made three clicks...) |
phadej
force-pushed
the
with-index
branch
5 times, most recently
from
f00f1ab
to
2985eaf
Compare
|
Pushed a variant using ekmett/comonad#54 |
|
Sorry, forgot to include autoclose message. Won't do that, to not torture Travis. |
|
Should we bump the next version to be 5.0 Reasoning, Technically the re-exporting doesn't break I'd make a patch to |
|
I'm a bit confused. How exactly is I don't have a strong opinion on what the next version of |
|
Imagine a downstream of build-depends: linear, indexed-traversableimport Linear.V2 -- from linear
import Data.Functor.WithIndex -- from indexed-traversable
--
vector :: V2 Int
vector = imap (someFunction :: E V2 -> () -> Int) (pure ())now, whether that compiles would depend on
EDIT: and |
|
So possible action points are either:
|
|
OK. But I think I'm still missing something. Supposing that we add restrictive upper version bounds for |
|
Yes it will fail to compile, as it does now. If we release TL;DR, the "which |
|
Alright. If I understand you correctly, the problem you are trying to prevent is that you might write code that only imports
Currently, (1) and (2) are independent, which means that you could accidentally change (2) without ever changing (1). By imposing appropriately restrictive version bounds, changing (2) (i.e., changing the version of Did I get all that right? |
Yes. |
|
Good to know. Here are some other thoughts:
Given that the Kmett-major version number is such a widely used convention, perhaps we should save ourselves some work and just make the next release be |
|
Good point about |
The next `lens` release will migrate to using the
`{Functor,Foldable,Traversable}WithIndex` classes from the
`indexed-traversable` package. As discussed in
#951 (comment), this poses a
challenge for downstream code that use instances of
`{Functor,Foldable,Traversable}WithIndex` from `indexed-traversable` while
also indirectly importing `lens`. This is because the code can succeed or fail
to compile depending on what version of `lens` is picked in the build plan,
even if there isn't a direct dependency declared against `lens`!
The best way to mitigate this possibility is to ensure that packages that
depend on `lens` and define `{Functor,Foldable,Traversable}WithIndex` have
appropriately tight version bounds on `lens`. At the time of writing, the most
recent Hackage release is `lens-4.19.*`, so we could ensure that packages
either declare `< 4.20` or `< 5`. As it turns out, many packages in the
Kmettiverse already declare `< 5`, so in order to avoid making more Hackage
revisions than we absolutely need to, we have decided to just bump the version
number to 5. In other words, we are bumping the "Kmett-major" version number.
It's probably a good time to do this regardless, as there are enough breaking
changes in the next release that it makes sense marketing-wise.
The next `lens` release will migrate to using the
`{Functor,Foldable,Traversable}WithIndex` classes from the
`indexed-traversable` package. As discussed in
#951 (comment), this poses a
challenge for downstream code that use instances of
`{Functor,Foldable,Traversable}WithIndex` from `indexed-traversable` while
also indirectly importing `lens`. This is because the code can succeed or fail
to compile depending on what version of `lens` is picked in the build plan,
even if there isn't a direct dependency declared against `lens`!
The best way to mitigate this possibility is to ensure that packages that
depend on `lens` and define `{Functor,Foldable,Traversable}WithIndex` have
appropriately tight version bounds on `lens`. At the time of writing, the most
recent Hackage release is `lens-4.19.*`, so we could ensure that packages
either declare `< 4.20` or `< 5`. As it turns out, many packages in the
Kmettiverse already declare `< 5`, so in order to avoid making more Hackage
revisions than we absolutely need to, we have decided to just bump the version
number to 5. In other words, we are bumping the "Kmett-major" version number.
It's probably a good time to do this regardless, as there are enough breaking
changes in the next release that it makes sense marketing-wise.
TODO:
freeversion (once it has instances)benchmark: traversals
Why the jump in between? Not sure.
Vector seems regressed, have to check if this is RULES not firing.
benchmark: folds
The
itoList/itraversedcombo doesn't seem to work well.