[Haskell-cafe] Generalizing (++) for monoids instead of using (<>)

[Alberto G. Corona]

Thinking aloud, I dónt know if the transition to more abstract type
signatures can be aleviated using language directives.
Someting like:

Restrict (++)  String -> String -> String

that locally would restrict the type within the module.

Althoug it does not avoid breaking the old code, It permits an easy fix.

Moreover, This may have applications in other contexts, for example
teaching, because the wild abstraction of the error messages is the
most difficult barrier in haskell learning.

Cheers

Alberto

2012/4/1 Thomas DuBuisson <thomas.dubuisson at gmail.com>:
> On Sun, Apr 1, 2012 at 1:58 PM, aditya bhargava
> <bluemangroupie at gmail.com> wrote:
>> After asking this question:
>> http://stackoverflow.com/questions/9963050/standard-way-of-joining-two-data-texts-without-mappend
>>
>> I found out that the new infix operator for `mappend` is (<>). I'm wondering
>> why ghc 7.4 didn't generalize (++) to work on monoids instead.
>
> Such decisions should really be made by the Haskell Prime committee
> (vs GHC HQ).  In Haskell there is a continuing tension between making
> things polymorphic and to keep the prelude functions monomorphic so
> they generate simple error messages (among other arguments).  At the
> point, the additional argument of any new definition of "Haskell"
> remaining backwards compatible also holds weight and this slows the
> rate-of-change.
>
> This is not a new issue, there are a number of functions that could be
> defined more generally (common example: map/fmap).  The problem making
> such changes is a matter of consensus and will to see things though.
>
> Cheers,
> Thomas
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe