<div class="gmail_quote">On Wed, Jan 13, 2010 at 7:57 AM, Peter Verswyvelen <span dir="ltr">&lt;<a href="mailto:bugfact@gmail.com" target="_blank">bugfact@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

A while ago, someone provided me a link to the paper &quot;Type Inference<br>
for Overloading without Restrictions&quot;<br>
<a href="http://www.dcc.ufmg.br/%7Ecamarao/ct-flops99.ps.gz" target="_blank">http://www.dcc.ufmg.br/~camarao/ct-flops99.ps.gz</a><br>
<br>
Although I don&#39;t understand everything in this paper, I wander what<br>
people&#39;s opinions are about this regarding a future Haskell language<br>
revision or extension?<br></blockquote><br>System CT (as it was defined in the Flops99 paper) is a core system<br>for constrained (parametric + ad-hoc) polymorphism, the main<br>difference with respect to Haskell type classes being that it uses a<br>
closed world approach to overloading (as it was defined in the Flops99 paper),<br>while Haskell type classes uses an open world. <br><br>Open means that principal types of overloaded symbols are explicitly<br>specified (in Haskell class declarations), and, informally speaking,<br>
satisfiability checking is performed only when overloading is resolved<br>(i.e. satisfiability is delayed until it cannot be delayed any longer). <br><br>Closed, on the other hand, means that principal types are determined<br>
(inferred) according to (definitions available in) the context (as<br>occurs in the normal case, of non-overloaded symbols). <br><br>For details, see e.g. [1].<br><br>A &quot;mixed&quot; approach, where annotation of types of overloaded symbols is<br>
not mandatory but satisfiability checking is done as in an open world<br>approach, is possible and advantageous.<br><br>Only prototype implementations exist to this date of system CT. <br>A prototype implementation of a mixed approach is currently under way.<br>
<div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Would a feature like this be preferable over typeclasses? </blockquote><br>The main disadvantage of system CT&#39;s closed world approach is the cost<br>of satisfiability checking. (However, this does not hold in the case of a mixed<br>
approach, where satisfiability checking is restrictd as in an open world). <br>The main advantage is that annotations (type classes) need not be mandatory<br>and a priori determined by the programmer.<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Would it be
practical to implement?</blockquote><div><br>Yes, I think so, in particular the mixed approach where satisfiability checking is<br>delayed (it is done only if there exist &quot;unreachable variables&quot; in the constraint set),<br>
as explained in [2].  We have recently sent a message with a link to our paper, that<br>describes this approach, as a 
proposal to solve Haskell&#39;s MPTC dilemma (without<br>the need of functional 
dependencies or another mechanism).<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Are people working on this?<br></blockquote>
<div><br>Yes. We are. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Thanks,<br>
<font color="#888888">Peter Verswyvelen<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</font></blockquote></div><br>Cheers,<br><br>Carlos<br><br>[1] Open and Closed World Approaches to Overloading: a Definition and Support for <br>    Coexistence, Carlos Camarão, Cristiano Vasconcellos, Lucília Figueiredo, João Nicola,<br>
    Journal of Universal Computer Science 13(6), 854-873, 2007.<br>    <a href="http://www.dcc.ufmg.br/~camarao/CT/open-closed.pdf">http://www.dcc.ufmg.br/~camarao/CT/open-closed.pdf</a><br><br>[2] A Solution to Haskell&#39;s Multi-paramemeter Type Class Dilemma,<br>
    Carlos Camarão, Rodrigo Ribeiro, Lucília Figueiredo, Cristiano Vasconcellos,<br>    SBLP&#39;2009 (13th Brazilian Symposium on Programming Languages), 2009.<br>    <a href="http://www.dcc.ufmg.br/~camarao/CT/solution-to-mptc-dilemma.pdf">http://www.dcc.ufmg.br/~camarao/CT/solution-to-mptc-dilemma.pdf</a><br>
<br>