Well of course the final decision about officially supported inference is yours to make, but you can't stop someone else from building other tools on top. I disagree with your strong preference for neat type inference. I think it would be a shame if BitC's type system gives up useful expressiveness just because it makes type inference too hard. I'm going to discuss that in another reply.
On Wed, Jul 9, 2014 at 10:06 PM, Jonathan S. Shapiro <[email protected]> wrote: > Where inference is concerned, we're going to end up in one of two positions: > > 1. Sound and complete inference for everything, with explicit type > annotations permitted but not required. > 2. Local inference, where procedure types must be explicitly declared. > > The thing that may drive us to [2] is polymorphic recursion, or > (equivalently) the variant in which methods may be overloaded on type. That > pushes you to semi-unification, which is not generally decidable. At that > point you have several options to choose from: > > 1. Require type annotations, at least in certain cases > 2. Give up complete inference, identifying the cases where the inference > algorithm will require annotations. I'm not sure I can tell the difference in meaning between those two. Are you saying only in the second case would we have some precise general understanding of the limitations of the inferencer? _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
