data-default WAS: [containers] Proposal: Change to the Data.Map Monoid

[Edward Kmett]

I'm more or less +/-0 on adding the class itself.

That said, I would be -1 on adding the class without adding a comprehensive
suite of instances, as that simply forces users into a worse situation than
they have now with more orphan instances and collisions between packages
that need or want them.

If this means that we don't do it at all, I'd prefer that to doing
something badly, and producing a result which is less useful than the
existing alternative.

-Edward


On Sat, May 24, 2014 at 11:11 PM, Markus Läll <markus.l2ll at gmail.com> wrote:

> 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 <john at repetae.net> wrote:
>
>> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
>
> --
> Markus Läll
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140525/abee7597/attachment.html>