Can you send out a link to Oleg's LtU post? I can't seem to find it.

On Fri, Jan 10, 2014 at 6:06 AM, Sandro Magi <[email protected]> wrote:

> Oleg just posted an interesting reference to an old paper [1] on LtU
> regarding overloading. Seems like it's exactly the type of overloading that
> Jonathan is looking for:
>
>   The introduction of unrestricted overloading in languages
>   with type systems based on implicit parametric polymorphism
>   generally destroys the principal type property: namely that
>   the type of every expression can uniformly be represented by
>   a single type expression over some set of type variables. As
>   a consequence, type inference in the presence of unrestricted
>   overloading can become a NP-complete problem. In this paper
>   we define the concept of parametric overloading as a restricted
>   form of overloading which is easily combined with parametric
>   polymorphism. Parametric overloading preserves the principal
>   type property, thereby allowing the design of efficient type
>   inference algorithms. We present sound type deduction systems,
>   both for predefined and programmer defined overloading. Finally
>   we state that parametric overloading can be resolved either
>   statically, at compile time, or dynamically, during program
>   execution.
>
> No free version seems accessible unfortunately. Oleg summarizes thusly:
>
>   His paper introduced what is in modern terms a local type
>   class with local instances. He cleverly avoids the incoherence
>   problem by a restriction (checked by the type checker) that an
>   overloaded operation doesn't escape the scope of its (local)
>   class declaration. The paper proves principal types, shows the
>   inference algorithm and describes two resolutions strategies,
>   static and dynamic. The static strategy is essentially
>   monomorphising (not quite different from template instantiation
>   in C++) and the dynamic strategy is essentially RTTI. (The
>   paper does not treat polymorphic recursion or higher-rank
>   types, which make monomorphising impossible.)
>
> Sandro
>
> [1] http://link.springer.com/chapter/10.1007%2F3-540-19027-9_9
>
>
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to