RFC: Cleanups

[snoyberg]

Now that mono-traversable has been in active use for a while, it's worth reviewing design points and seeing if we can do better. I've given some thought to the following points, and would appreciate feedback on them:

• Get rid of MinLen. I originally added it as a fancier way of doing NonNull. In practice, I think MinLen just complicates usage and error messages, and isn't particularly useful most of the time. If people like it, it could certainly be moved to a separate package
• Data.ByteVector is misplaced here, and can go elsewhere (maybe chunked-data or classy-prelude)
• We could have a mono-traversable-classes package, which depends on very few packages, and then mono-traversable itself reexports those classes together with orphan instances. This would lower the barrier on providing typeclass instances
• chunked-data provides LazySequence, I think that fits better in the same package as Data.Sequences. (Whether that should still be in mono-traversable is a fair question, but I think its monomorphic nature is a really good fit.)
• The Map-like abstraction I started on in jump is, IMO, an improvement on what we have now. The strictly monomorphic nature of Data.Containers isn't very useful in practice, and prevents some useful methods like difference in its full generality. I'd recommend consolidating on the jump-style abstraction, and then decide if we put that in jump, mono-traversable, or a separate package for container-like abstractions (containers-classes?)
• Early on we decided to prefix all MonoFoldable, MonoFunctor, and MonoTraversable function names with o. I still think this makes sense for MonoFunctor and MonoTraversable, where the monomorphic functions we provide are not strictly more general than the polymorphic versions. But in the case of MonoFoldable, I believe we want end-users to treat this as a drop-in replacement for Foldable. So I propose: in the case of only a MonoFoldable constraint, remove the prefix o.
• We can do a pass over all of the typeclasses and see if any should be removed/renamed/split up.

I'm not 100% behind all of these ideas, I'm sharing them now to try and elicit useful feedback.

[gregwebs]

I have once found it useful to declare a MinLen of 2. I think the o prefix is still useful to avoid import conflicts and to give mono-traversable the chance to make differences with foldable and the opportunity to see different error messages.re-exporting without the prefix seems to work for classy-prelude

[snoyberg]

Actually, having a Prelude with both the Data.Foldable and Data.MonoTraversable identifiers all exported sounds like an interesting idea. OK, scratch the renaming thought.

Is there any objection then to other things I put in this list?

[gregwebs]

Sounds fine. I like the idea of MinLen as long as NonNull can still present its own interface and error messages

[snoyberg]

Alright, it took a while for me to free up time, but I've finally taken a stab at this. The work is on various various branches of different repos:

• https://github.com/snoyberg/mono-traversable/tree/95-cleanup
• https://github.com/fpco/chunked-data/tree/mono-traversable-1
• https://github.com/snoyberg/classy-prelude/tree/mono-traversable-1

Unexpected outcomes:

• chunked-data no longer depends on mono-traversable at all, making that package potentially more widely useful
• I added a module Data.MonoTraversable.Unprefixed with all of the identifiers from Data.MonoTraversable, minus the o prefix. ClassyPrelude then imports that, meaning there's less code to maintain in ClassyPrelude (making it easier to synchronize added identifiers)
• I generalized a number of functions from Monad to Applicative for GHC 7.10 and later
• A number of stray functions lying around in ClassyPrelude have moved into mono-traversable. The basic idea is: I'd like to define as little in ClassyPrelude itself as possible

This addresses most of the points above. There are two questions that have come up for me which are worth exploring:

• I moved the DList instances to mono-traversable-instances, though since that's a relatively cheap dependency I'm OK with moving it back if you'd prefer
• I mentioned overhauling the Data.Containers module to be non-monomorphic. Unfortunately, I can't figure out a way to do that and get good unification between Sets and Maps. Possibilities:
  • Split out the module as-is to a new package, and consider making improvements in the future
  • Add a bunch of Map and Set suffixes and don't have the same identifiers for the two data types. I'm overall -1 on this, as it breaks a lot of code and makes new code significantly uglier

I have no particular time pressure on releasing these changes, so I'm fine with taking a bit more time if warranted.

[gregwebs]

Sounds great! As long as documentation mentions mono-traversable-instances it doesn't matter to me if stuff is moved there. You should make all the changes you are confident in now and come back to Containers later.

[snoyberg]

This is merged to master, closing. Thanks for all the feedback :)

[saurabhnanda]

I'm not sure if I'm qualified to comment here, or if this is the right place to give feedback, but here's my experience as an application author (as against a library author).

I was exposed to ClassyPrelude via the Yesod scaffolding template and I was under the impression that it's just a saner version of the same old Prelude functions that I'm used to. That is, until I was hit with http://lpaste.net/178218 The error message made absolutely no sense to me, and for a moment I thought that ClassyPrelude had changed the core list ([]) type to act funny.

I dug deeper into ClassyPrelude and discovered MonoTraversable. However, I found no mention of MinLen in the MonoTraversable documentation. Digging even deeper made me realise that MinLen was there in 0.10.2 (which is what the Yesod scaffolding template gives up to LTS 6.12). Finally, discovering the ChangeLog pointed me to this issue and made me realise that MinLen was pretty much being deprecated.

Now, I'm in a fix. I'm on LTS-6.6 which is frozen (?) to v0.10.2 of MonoTraversable, which has defined regular functions like head in terms of MinLen, which is clearly not the way forward. However Data.NotNull in that version is clearly marked as experimental.

I know that I'll have to bite the bullet and figure out how to get the latest version of ClassyPrelude and MonoTraversable to work with LTS-6.6. However, here are a bunch of related questions:

• Is there a better way to communicate this deprecation?
• If MinLen is deprecated, would it be good idea to bump-up the version of ClassyPrelude in the Yesod scaffolding templates?
• If Data.NotNull is the way forward, is it a good idea to replace the plain old list [] with the appropriate type from Data.NotNull? Will it work with other libraries/functions that expect a regular list []?
• What's the practical difference between Data.List.NonEmpty and Data.NonNull?