For me, the default makes sense, too, in the very specialised cases (in the
world of things that have types) like settings of a web server or cvs
parser, where the application author defined it for to quickly launch some
program or function. The 'default' there would mean 'something sensible',
the meaning of which I don't yet care about. Probably the author of the
package is also a frequent user of the default to test the thing he is
writing.
So I would be +1 for adding a class to the base (as many would otherwise
re-implement it anyway), but with no instances. The module could also state
the policy behind the class, i.e "don't write defaults for widely used
types/types that you didn't create yourself" or whatever else people agree
upon.
On Thu, May 22, 2014 at 10:08 PM, John Meacham
The issue i have is not the concept, I have actually written similar classes in a few situations, the issue is that there is little value in a shared implementation of it. There is no underlying meaning to 'default' that crosses project boundries. seeing 'Default a => blah ' in a type signature doesn't convey any useful information about a other than at some point, someone somewhere added a to a list based on their current whim.
That said, I have written the class a few times, and that is fine, just because the code looks the same it doesn't necesarily mean it is conceptually reusable because they had a specific meaning. looking at my codebase I find
PerlDefault - what the value would default to if 'undef' in perl. used when generating perl code. HsSynDefault - haskell syntax default, bits of haskell syntax (HsExp, HsDecl, etc..) with the annotations set to default leaving only the source bits to fill in.
But both have defined meanings and when I see them in a type signature, it conveys useful information.
-- John Meacham - http://notanumber.net/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Markus Läll