<div dir="ltr">That seems worth pursuing. <div><br></div><div>If that works, it'd turn the defaulting rules fix from a fishing expedition to simply adding a couple of extra classes to the list of approved basic defaultings.<div>
<br></div><div>-Edward</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 26, 2013 at 4:54 PM, Ganesh Sittampalam <span dir="ltr"><<a href="mailto:ganesh@earth.li" target="_blank">ganesh@earth.li</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<div class="im"><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 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 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>
</div><div class="im">> <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>
</div><div class="im">> <<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>>> wrote:<br>
><br>
> Just to throw another curveball at this conversation, what about<br>
> a general, ad-hoc solution for 'typeclass defaults'? The logic<br>
> goes like this: Is there an "ambiguous type variable" error 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. Why<br>
> not just provide this general capability for arbitrary 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 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>
</div><div class="im">> <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 I<br>
> would urge programmers to import that explicitly.<br>
><br>
><br>
> This one liner would take the place of the current 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 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>
</div>> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>><br>
<div class="im">> <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>
</div>> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>><br>
<div class="im">> <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>
</div>> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>><br>
<div class="HOEnZb"><div class="h5">> <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>
</div></div></blockquote></div><br></div>