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

[João Cristóvão]

Hi Brian, John,

While I see your point regarding type inference, I have a hard time seing
your argument regarding triviality.

Of course Data.Default instances for trivial types will be trivial. But
that's hardly what I'm arguing about. Nor it is to save a few characters,
from writing def instead of defaultStructureWhatever.

The case is that for very long and complex structures, filled with trivial
values, and with an obvious default value, writing that default value is a
task best left for the compiler, with the help of generics.

> to... save typing?

Yes, indeed, to save typing a lot of fields with trivial values, and then
modifying it again if we add another trivial Text or List or IntMap value.

Of course, this only works if there are default values for the trivial
types, and what better place for this than Base.

One could argue that there is already generic support for Monoids/mempty,
but I argue that the subset of types that can have a default value is much
bigger than those who have a Monoid instance.

> and the ability to choose different defaults for varying circumstances

Well, in that case, you should not provide a Data.Default instance, of
course.

But there are certainly a lot of cases where the default value does come in
handy, initial value of a fold, interacting with C code that requires empty
structures, etc.

If I am not seeing this right, or there is a better approach, please let me
know.

João


2014-05-22 1:43 GMT+01:00 John Wiegley <johnw at newartisans.com>:

> >>>>> Bryan O'Sullivan <bos at serpentine.com> writes:
>
> > I agree. Default is the bad kind of trivial: it gives you nothing, but in
> > exchange takes away type inference and the ability to choose different
> > defaults for varying circumstances. I wouldn't support adding it to base,
> > and prefer to avoid packages that use it.
>
> I feel similarly, Bryan.  All Data.Default seems to achieve is to overload
> a
> single name to... save typing?
>
> If I'm already reading the documentation for a function I need to call,
> there's no reason the documentation can't also mention the default value I
> should be using, hopefully with an example of what typical specializations
> look like.
>
> Having the name 'def' gives me little added benefit, since I don't know
> what
> to do with the value other than pass it.  And if that's going to be how
> it's
> used the majority of the time, the library author could just provide a
> variant
> of the function which assumes the default.
>
> John
> _______________________________________________
> 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/20140522/7aded7a6/attachment-0001.html>