Just to throw another curveball at this conversation, what about a general, ad-hoc solution for 'typeclass defaults'? The logic goes like this: Is there an "ambiguous type variable" error due to the use of the IsString typeclass? Try defaulting to the String instance. If that doesn't work, try defaulting to Text. Repeat for a finite, explicit list of instances. If none of these defaults are successful, type error. We have hard-coded this sort of behavior into the Num class. Why not just provide this general capability for arbitrary classes? Or at least hard-code it into IsString as well. In the absence of this sort of solution, +1 to Edward's original proposal. The "o" proposal is not viable because the oft-needed parens make it confusing and irritating to the new Haskeller. -- Dan Burton On Mon, Aug 26, 2013 at 12:41 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Mon, 26 Aug 2013, Gabriel Gonzalez wrote:
I'm guessing this is sarcastic, but I just want to clarify what I
understood Henning's proposal to be. He's not saying we should provide an `o` function in the standard library, but rather encourage users to define their own.
Yes. I would be ok if packages provide this function, but I would urge programmers to import that explicitly.
This one liner would take the place of the current line that they devote
right now to `OverloadedStrings` .
right
However, the analogy is still apt since the exact same line of reasoning
applies to overloaded numeric literals where we currently rely on defaulting to solve this problem.
I always use -Wall and thus I am warned about when defaulting takes place. Thus I am confident that I do not rely on defaulting in my code.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries