PS: I'm not convinced that it's worth the overhead of adding a new class. Modifying the defaulting rules would probably be enough, although it does involve one new feature, namely that it must default IsString [beta] as well as IsString alpha. Simon | -----Original Message----- | From: Simon Peyton-Jones | Sent: 27 August 2013 08:27 | To: 'Ganesh Sittampalam'; Edward Kmett | Cc: Haskell Libraries | Subject: RE: Proposal: Improving the IsString String instance | | 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- | evaluation.html#extended-default-rules | | 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 | <dag.odenhall@gmail.com | | > <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 | | > <danburton.email@gmail.com <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 | | > <lemming@henning-thielemann.de | | > <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