Skip to content

RFC: Cleanups #95

@snoyberg

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions