Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Review Suggested Edit

You can't approve or reject suggested edits because you haven't yet earned the Edit Posts ability.

There's good reason to believe this is simply historical accident. The `Semialign` class came first, and used to include `zip` and `zipWith` directly. When those members were separated out into their own class, the motivation was types that had `align` but not `zip` (one example is [`NEMap`](https://hackage.haskell.org/package/nonempty-containers-0.3.4.5/docs/Data-Map-NonEmpty.html#t:NEMap)), so `Zip` got the superclass instead of `Semialign`. In retrospect, perhaps making the two classes independent and defining a laws-only subclass of both would have been better.

There's good reason to believe this is simply a **historical accident**.
The `Semialign` class came first and used to include `zip` and `zipWith` directly. When those members were separated out into their own class, the motivation was types that had `align` but not `zip` (one example is [`NEMap`](https://hackage.haskell.org/package/nonempty-containers-0.3.4.5/docs/Data-Map-NonEmpty.html#t:NEMap)), so `Zip` got the superclass instead of `Semialign`.
In retrospect, perhaps making the two classes independent and defining a laws-only subclass of both would have been better.

Communities

Review Suggested Edit