On Thu, Feb 12, 2015 at 1:21 AM, William ML Leslie < [email protected]> wrote:
> BitC's intended audience has additional bearing on this, and that is what > we're trying to discuss. BitC cannot entertain the same level of magic as > other languages might be able to get away with. We want native performance > out of what may be generic or higher-order calls. > That's very well said. But Keean is aware that we have done at least a day or two of work on type systems. I think that he is wrestling with an un-voiced distaste, and I think his distaste is well-founded. I have been wrestling similarly, and it is only this morning that I can put words on the issue (I hope): If function types carry arities, we lose both principal types and most general types I'm not that worried about principal typings. GADTs are good things, and once we admit them there isn't a principal type anymore. The loss of "most general type" is more serious. If we then go ahead and adopt Option 3 (implicit lambdas), then this *particular* loss of most general types has no impact on program behavior. But it is definitely true that we will have cases that can validly be inferred with two different interpretations, and this is generally a bad thing from a type reconstruction perspective. At the very least, it will mean that there are places where we will require annotations that would otherwise be unnecessary. No often, but sometimes. Note, however, that I'm not convinced we should still be doing global inference (for several reasons). If we are only doing local inference, this whole problem ceases to be a concern at all. I'd kind of like not to back off that far. I'm presently considering whether the combination of declared types at module boundaries plus whole-module compilation is "local enough" to keep inference decidable in the presence of polymorphic recursion and certain kinds of overloading. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
