Re: Proposal: Improving the IsString String instance

Couldn't it work (with suitable extensions to the list of blessed classes) with Henning's IsCharList suggestion? The unresolved constraint would be IsCharList a. On 26/08/2013 21:47, Edward Kmett wrote:

The problem is ExtendedDefaultRules only works when the whole type is unknown. If we know part of the type e.g. that it is [a] for some a as we figure out from length, or that it is (f a), then it doesn't kick in.

print works because "hello" :: (IsString a, Show a) => a

knows nothing about the argument a

and Show is included in the EDR list of blessed classes.

If at the repl you turn on OverloadedStrings and EDR

showList "hello" ""

will still blow up, because it can know you have an argument [a] with a Show a constraint on it, and IsString [a], so it fails to meet the fairly simplistic conditions required by EDR.

-Edward

On Mon, Aug 26, 2013 at 4:34 PM, Dag Odenhall mailto:dag.odenhall@gmail.com> wrote:

|ExtendedDefaultRules| already provides this to some extent, for example it makes |print "hello"| work without type information.

On Mon, Aug 26, 2013 at 10:09 PM, Dan Burton mailto:danburton.email@gmail.com> wrote:

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 mailto: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 mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries