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

Already on GitHub? Sign in to your account

Generalized types for commonly convenient folds #33

merged 2 commits into from Mar 5, 2014


None yet
2 participants

dmcclean commented Mar 5, 2014

I changed the prelude to export product, minimum, and maximum from Data.Foldable instead of from Prelude.

This shouldn't hurt anyone because it's in the base package, and so is the Foldable instance for []. It also matches what we did with sum.


bjornbm commented Mar 5, 2014

I've sort of limited the ambition of the prelude to export only the haskell Prelude, except where there is a “conflict” in naming with dimensional. I agree that replacing these functions should't harm anyone, but it does raise the question of how far we want to go in this directions (see e.g. classy-prelude for why I understand is an extreme example).

maximum and minimum are more relevant and justifiable as they can actually be used on Foldables of Dimensionals, but changing product is more gratuitous as it has no direct relation to dimensional. EDIT: I just saw #34.

Neither of these are specialized for Dimensional (as opposed to sum) so a clients needing the foldable variations are at least be no worse of than if they were not using Dimensional.

Convince me! ;)


dmcclean commented Mar 5, 2014

I agree with that as a goal, as opposed to adopting classy-prelude or one of the other alternatives.

But I feel like this change is pretty harmless, because the same names mean the same things and work with all the same types. As you said, maximum and minimum were my main goals, because I wanted to use them at types of the form Data.Vector (Quantity d Double).

While I was doing that, I read through the rest of the list to see if anything else made sense, and I noticed that we had sum but not product. Then I realized that sum works at any dimension but product only works at DOne. Then I thought about writing a product definition next to the sum one. Then I had the idea about the Num instance (but forgot about the post you had written explaining the pitfalls, again, oops).

I don't feel especially strongly about the product thing, especially if the Num is still a bad idea (which it may very well be, I haven't gotten a chance to look at that yet since I have been busy at the office).

I would like the minimum and maximum things because otherwise I will need to do hiding and all that in quite a few places. I agree there is a fuzzy line about how far to go in this direction, though.

bjornbm added a commit that referenced this pull request Mar 5, 2014

Merge pull request #33 from dmcclean/folds
Generalized types for commonly convenient folds

@bjornbm bjornbm merged commit 5c55721 into bjornbm:master Mar 5, 2014


bjornbm commented Mar 5, 2014

OK. I'm not sure product will stay. It will depend on our success with Num Dimensionless.

@dmcclean dmcclean deleted the dmcclean:folds branch Sep 18, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment