<div dir="ltr">Mostly, I am curious about general efforts in the area.<div><br></div><div>I personally would like a mechanism by which type class instances may be used for type inference. Specifically, I wish there were some mechanism by which I could say, if there is only one instance of a typeclass available, choose it and proceed with type inference. This is somewhat what defaulting currently allows. Here is some code that I would like to "emulate"</div><div><br></div><div><div><font face="monospace, monospace">class FromInt a where</font></div><div><font face="monospace, monospace">  fromInt :: Int -> a</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">instance FromInt String where</font></div><div><font face="monospace, monospace">  fromInt = show</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">instance FromInt Int where</font></div><div><font face="monospace, monospace">  fromInt = id</font></div><div><font face="monospace, monospace"><br></font></div><div><div><font face="monospace, monospace">class Go a where</font></div><div><font face="monospace, monospace">  go :: a -> IO ()</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">instance Go Int where<br></font></div><div><font face="monospace, monospace">  go = print</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">-- No type signature necessary anywhere</font></div><div><font face="monospace, monospace">main = go $ fromInt 3</font></div></div></div><div><br></div><div>Here, I would like `fromInt 3` to be defaulted to `Int`, as that is the only possible instance that `Go` allows; once it is defaulted, then type inference can continue as normal, choosing the appropriate `FromInt` instance. (Of course, I do not mean for the code as written above to have backwards incompatible behaviour; instead probably some syntactic changes would indicate that "Go" is somehow defaultable, etc etc)<font face="monospace, monospace"><br></font></div><div><br></div><div>Note that this proposal is far from "fleshed out" and I don't have any suggestions for how Haskell might move in such a direction in the immediate future; I am more just curious whether work has been done in this area or what other options may be. Using typeclass instances for type resolution would allow clever design to get rid of "ambiguous variable" errors, and allow us to write cleaner code without as many type annotations (which is what defaulting allows for numeric literals). </div><div><br></div><div>-- Andrew</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 30, 2014 at 8:20 AM, Kim-Ee Yeoh <span dir="ltr"><<a href="mailto:ky3@atamo.com" target="_blank">ky3@atamo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div class="gmail_extra"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wish Haskell gave typeclass authors more control over defaulting. <br></blockquote><br></div></span><div class="gmail_extra">If you could flesh out your case more, social momentum will build more rapidly to push things through.<br><br></div><div class="gmail_extra">What concrete problem are you trying to solve with finer-grained defaulting?<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div class="gmail_extra"><br clear="all"><div><div>-- Kim-Ee</div></div>
</div></font></span></div>
</blockquote></div><br></div></div>