On Fri, Jan 9, 2015 at 12:27 AM, Keean Schupke <[email protected]> wrote:
> When an instance value is passed explicitly, we still have a place in >> the code that identifies which functions need to be specialised, and >> what they need to be specialised against. >> >> If implicit resolution is guided by TLS, dictionaries must /always/ be >> maintained, even if they are never used. The alternative is >> specialising all of the code for each dynamic contour. > > > It sounds like we are saying the same thing. For specialisation to occur > in any arbitrary function there must be only one global instance for any > given type. It requires coherence. > There does not need to be one global instance for any given type. There only needs to be one global *default* instance for any given type. When we specialize, we remember which instance was used in the specialization (perhaps through name mangling). If an explicit instance override is used, we simply specialize differently and record *that* instance in the specialization. What's important in the end is that we know which procedure used what. Strictly speaking, I concede that I am stretching the definition of "coherence" here, extending it in a fairly obvious way to something (the instance) that is not quite a type but can be used very similarly for directed specialization. If instances are incoherent, you need to indicate which one to use by > passing value, which prevents specialisation if the value is first class, > because you don't know from which context the current function will be > called. > And this is why I keep insisting that instances aren't values, and I keep emphasizing that they need to be statically resolvable constant bindings. And I don't by the "from which context the function will be called" part. By the time the function is called, it will already have been specialized. The concern at that point is merely to ensure that the calling context and the called function agree on the post-specialization name of the thing to be called. I think there is some confusion arising here from the assumption that a parametric function is *one* function. It isn't. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
