<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 27, 2013 at 3:27 AM, Simon Peyton-Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If I understand aright, the problem is that we end up with constraints like<br>
IsString alpha<br>
or<br>
IsString [beta]<br>
where alpha or beta are otherwise-unconstrained unification variables. Under those circumstances we'd like to default to IsString String.<br>
<br>
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.<br></blockquote><div> <br></div><div>I may be misunderstanding you, as I thought I understood EDR pretty well.<div>
<br></div><div><span style="color:rgb(0,0,0)"><font face="arial, helvetica, sans-serif">Defaulting and EDR both as I understand it look for a type variable a that only occurs in constraints of the forms (C1 a, C2 a, ..., Cn a), but </font></span></div>
<div><span style="color:rgb(0,0,0)"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><span style="color:rgb(0,0,0)"><font face="arial, helvetica, sans-serif">Your (Show alpha, Num alpha) works because it is in that form.</font></span></div>
<div><span style="color:rgb(0,0,0)"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><span style="color:rgb(0,0,0)"><font face="arial, helvetica, sans-serif">IsString a works, with appropriate changes to defaulting, b</font></span><span style="color:rgb(0,0,0)"><font face="arial, helvetica, sans-serif">ut </font></span><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">IsString [a] doesn't look like it would meet the condition, and my recollection from trying variations on this trick, it doesn't work in practice.</span></div>
<div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">That was what Ganesh's proposal was to facilitate. It ensured that we had some class in form for the </span><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">(C1 a, C2 a, ..., Cn a) check.</span></div>
<div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">If we can get by without that, I'm 100% for it!</span></div>
<div><br></div><div><font color="#000000" face="monospace" size="3">-Edward</font></div><div class="gmail_extra"><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
We've already extended it for GHCi<br>
<a href="http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules" target="_blank">http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules</a><br>
<br>
I don't think this would be controversial. The path seems to be:<br>
propose a concrete extension to the rules,<br>
specify when it's enabled<br>
get everyone to agree<br>
provide a patch (relevant code is in TcSimplify.applyDefaultingRules)<br>
<span class=""><font color="#888888"><br>
Simon<br>
</font></span><div class=""><div class="h5"><br>
| -----Original Message-----<br>
| From: Libraries [mailto:<a href="mailto:libraries-bounces@haskell.org">libraries-bounces@haskell.org</a>] On Behalf Of<br>
| Ganesh Sittampalam<br>
| Sent: 26 August 2013 21:55<br>
| To: Edward Kmett<br>
| Cc: Haskell Libraries<br>
| Subject: Re: Proposal: Improving the IsString String instance<br>
|<br>
| Couldn't it work (with suitable extensions to the list of blessed<br>
| classes) with Henning's IsCharList suggestion? The unresolved constraint<br>
| would be IsCharList a.<br>
|<br>
| On 26/08/2013 21:47, Edward Kmett wrote:<br>
| > The problem is ExtendedDefaultRules only works when the whole type is<br>
| > unknown. If we know part of the type e.g. that it is [a] for some a as<br>
| > we figure out from length, or that it is (f a), then it doesn't kick<br>
| in.<br>
| ><br>
| > print works because "hello" :: (IsString a, Show a) => a<br>
| ><br>
| > knows nothing about the argument a<br>
| ><br>
| > and Show is included in the EDR list of blessed classes.<br>
| ><br>
| > If at the repl you turn on OverloadedStrings and EDR<br>
| ><br>
| > showList "hello" ""<br>
| ><br>
| > will still blow up, because it can know you have an argument [a] with<br>
| a<br>
| > Show a constraint on it, and IsString [a], so it fails to meet the<br>
| > fairly simplistic conditions required by EDR.<br>
| ><br>
| > -Edward<br>
| ><br>
| ><br>
| > On Mon, Aug 26, 2013 at 4:34 PM, Dag Odenhall <<a href="mailto:dag.odenhall@gmail.com">dag.odenhall@gmail.com</a><br>
| > <mailto:<a href="mailto:dag.odenhall@gmail.com">dag.odenhall@gmail.com</a>>> wrote:<br>
| ><br>
| > |ExtendedDefaultRules| already provides this to some extent, for<br>
| > example it makes |print "hello"| work without type information.<br>
| ><br>
| ><br>
| ><br>
| > On Mon, Aug 26, 2013 at 10:09 PM, Dan Burton<br>
| > <<a href="mailto:danburton.email@gmail.com">danburton.email@gmail.com</a> <mailto:<a href="mailto:danburton.email@gmail.com">danburton.email@gmail.com</a>>><br>
| wrote:<br>
| ><br>
| > Just to throw another curveball at this conversation, what<br>
| about<br>
| > a general, ad-hoc solution for 'typeclass defaults'? The logic<br>
| > goes like this: Is there an "ambiguous type variable" error<br>
| due<br>
| > to the use of the IsString typeclass? Try defaulting to the<br>
| > String instance. If that doesn't work, try defaulting to Text.<br>
| > Repeat for a finite, explicit list of instances. If none of<br>
| > these defaults are successful, type error.<br>
| ><br>
| > We have hard-coded this sort of behavior into the Num class.<br>
| Why<br>
| > not just provide this general capability for arbitrary<br>
| classes?<br>
| > Or at least hard-code it into IsString as well.<br>
| ><br>
| > In the absence of this sort of solution, +1 to Edward's<br>
| original<br>
| > proposal.<br>
| ><br>
| > The "o" proposal is not viable because the oft-needed parens<br>
| > make it confusing and irritating to the new Haskeller.<br>
| ><br>
| > -- Dan Burton<br>
| ><br>
| ><br>
| > On Mon, Aug 26, 2013 at 12:41 PM, Henning Thielemann<br>
| > <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a><br>
| > <mailto:<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>>> wrote:<br>
| ><br>
| ><br>
| > On Mon, 26 Aug 2013, Gabriel Gonzalez wrote:<br>
| ><br>
| > I'm guessing this is sarcastic, but I just want to<br>
| > clarify what I understood Henning's proposal to be.<br>
| > He's not saying we should provide an `o` function in<br>
| > the standard library, but rather encourage users to<br>
| > define their own.<br>
| ><br>
| ><br>
| > Yes. I would be ok if packages provide this function, but<br>
| I<br>
| > would urge programmers to import that explicitly.<br>
| ><br>
| ><br>
| > This one liner would take the place of the current<br>
| line<br>
| > that they devote right now to `OverloadedStrings` .<br>
| ><br>
| ><br>
| > right<br>
| ><br>
| ><br>
| > However, the analogy is still apt since the exact same<br>
| > line of reasoning applies to overloaded numeric<br>
| > literals where we currently rely on defaulting to<br>
| solve<br>
| > this problem.<br>
| ><br>
| ><br>
| > I always use -Wall and thus I am warned about when<br>
| > defaulting takes place. Thus I am confident that I do not<br>
| > rely on defaulting in my code.<br>
| ><br>
| > _______________________________________________<br>
| > Libraries mailing list<br>
| > <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>><br>
| > <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
| ><br>
| ><br>
| ><br>
| > _______________________________________________<br>
| > Libraries mailing list<br>
| > <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>><br>
| > <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
| ><br>
| ><br>
| ><br>
| > _______________________________________________<br>
| > Libraries mailing list<br>
| > <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>><br>
| > <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
| ><br>
| ><br>
| ><br>
| ><br>
| > _______________________________________________<br>
| > Libraries mailing list<br>
| > <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
| > <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
| ><br>
|<br>
|<br>
| _______________________________________________<br>
| Libraries mailing list<br>
| <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
| <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div></div>