Re: Proposal: Improving the IsString String instance

We're having a hackathon here in Zurich next weekend. I'll be happy to give this a shot (or get someone attending to do it). Doesn't look too complicated. The bigger unknown are more potential build issues with GHC. On 27 Aug 2013, at 09:27, Simon Peyton-Jones wrote:

If I understand aright, the problem is that we end up with constraints like IsString alpha or IsString [beta] where alpha or beta are otherwise-unconstrained unification variables. Under those circumstances we'd like to default to IsString String.

This is *exactly* what the current type-class-defaulting mechanism does. Eg with (show 3) you get (Show alpha, Num alpha) and want to choose alpha to be something sensible.

We've already extended it for GHCi http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluati...

I don't think this would be controversial. The path seems to be: propose a concrete extension to the rules, specify when it's enabled get everyone to agree provide a patch (relevant code is in TcSimplify.applyDefaultingRules)

Simon

| -----Original Message----- | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of | Ganesh Sittampalam | Sent: 26 August 2013 21:55 | To: Edward Kmett | Cc: Haskell Libraries | Subject: 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 | > | | | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries

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