I have no strong opinion on Keann's "views" notion, excepting that I don't quite understand how it manifests in practical code. I am beginning to suspect that it is more a matter of idiom than code generation. If so, I want to be assured that the resulting code is efficient, but I believe, provisionally, that it can be. I see no intrinsic reason to believe that "views" are better or worse than differing CPOs in the case of sort. I don't feel like I have a good intuition for how the views notion generalizes to other use cases. I also don't have an intuition for how this interacts with naive programmer intuitions (usability).
Naively, lacking the benefit of pragmatic experience, it seems to me that sort(reversed(myVec)) is objectively as efficient as using reverse Ord 'a sort myVec Having written it, it seems to me initially that it may even be clearer after a little head scratching. How it translates into human perception seems hard to predict. How it translates when multiple type parameters are involved seems much harder to understand, but for that very reason it is a progressively less likely case and therefore progressively less important. I'm concerned that sort(reversed(myVec)) seems prone to copies if done naïvely. That said, if "views" provide a *de facto* idiom that subsumes most uses of named instances, then that seems good given that named instances seem to raise significant concerns of complexity. We may still [perhaps] need named instances for other reasons, but questions of feasible idiom are part of language design. The one thing I'm dead certain about is that I'm glad Keann graciously agreed to join us. I'm learning already! I'm mildly concerned that using CPO as our exemplar may delude us, precisely because CPO admits reverse(). I'm not sure this use case is general enough to serve as a design guide. q: can anybody suggest a relation that does not readily translate into the view concept? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
