I just want to revisit compile time specialisation, Sorry for picking this post, but it does express the objections:
On 9 January 2015 at 07:52, Jonathan S. Shapiro <[email protected]> wrote: > Yuck! This is quadruple plus ungood. What you've done here, in effect, is > to mix up records and overloading and stack allocation. These seem like > horrible things to mix up. Especially since instances are NOT locals and > CANNOT be locals if the coherence of implicit instances is to be preserved. > The problem is the resolution of instances I think. If we have dynamic scoping we can say the top of the dynamic instance stack is the instance that will be chosen for that type. This seems fine to me. > > Making instances dynamic in this way utterly destroys our ability to do > compile-time specialization! > I don't see why, lets say we have: test1(list<int> x) { using int3 return (sort x) } In this case we know that int3 will be top of the stack, so we don't care what the rest of the dynamic stack is, and can elaborate sort with an inlined compare function. However it is true that dynamic-scope reduces the opportunities for inlining, and it would be good if all implicit uses of type-classes were inlineable. Maybe lexical scoping would be a good compromise? I am still very keen on the idea of combining records and instances (I woud be interested to see what you had in mind for kind-classes), and the idea that records/type-classes should need to be brought into scope for implicit resolution. Lexical scoping would still allow the thread example to work, but would also allow static inlining of all implicit uses of type-class/records. Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
