But if you have types at the module boundary, inside the module you have the 'whole program', so it is safe to make that assumption for inference.
Keean. On 12 Feb 2015 15:03, "Jonathan S. Shapiro" <[email protected]> wrote: > On Thu, Feb 12, 2015 at 12:10 AM, Keean Schupke <[email protected]> wrote: > >> Its not a problem, in the case where you only pass in the function as an >> argument, it must be completely applied, so you can infer its complete >> (local polymorphic) type from its use. >> > > Counter example: > > def g f x = f x > > We know that f is applied to a single argument, but we do not know that it > has arity 1. Hmm. I suppose we do, because Option 1 requires explicit > lambda insertion. But we would even know this under Option 3 (implicit > insertion). So we would know that the formal parameter has arity one, but > we would not know that the *actual* parameter has arity one. > > Though note we only know _f_ has arity one by virtue of arity inference! > > >> In the more complex case where you pass in a function, partially apply >> it, and return the rest, you are okay if you have the whole program. >> > But of course we do not assume this in BitC. In fact, we categorically > reject the whole program assumption. > > I think types should be specified at module boundaries in any case, as you >> want a stable interface. >> > I agree with you. And a consequence of this turns out to be that you are > nearly reduced to local inference. Which is actually good, because > polymorphic recursion is a useful thing to be able to do without having > your inference engine blow up in your face... > > > shap > > _______________________________________________ > 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
