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@newartisans.com>:
>>>>> Bryan O'Sullivan <bos@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries