
I don't agree to Empty either. As I mentioned, the most compelling use cases for
Default I see are things like ParserOptions and ConnectionInfo.
Empty could be a separate typeclass with a different set of instances. It should
probably come with laws (its monofoldable length/size should be 0).
Roman
* João Cristóvão
Hi Roman, Daniel,
I do see your point, and I don't find it a problem. In those particular cases perhaps it only makes sense to define a Default value for the same cases as mempty applies, namely for Sum and Product.
So, I'm fine with not including default values for Int, Bool, Float...
However, I'm not sure I agree with calling it Empty. You might want to use Default with your own Algebraic data type where the concept of Default makes sense, but the concept of Empty does not. The Empty name may be a little too misleading (as mempty is already for Monoid, see the Product newtype).
Cheers, João
2014-05-22 9:10 GMT+01:00 Daniel Trstenjak
: Hi João,
... with an obvious default value ...
I think that's the problem some people have, that the default values for several types aren't obvious at all and therefore you have to know the default values of several types to easily read code using 'def'.
The default values for container like types - like String or List - are mostly quite obvious, they're just the empty ones. But the default values for types like Int, Bool of Float aren't that obvious and they certainly don't make sense in any use case.
That's also the reason why an Empty type class was advocated instead of the Default one, because than it's really obvious what the result for container like types is.
Greetings, Daniel _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries