On Mon, Jul 29, 2013 at 3:00 AM, William ML Leslie < [email protected]> wrote:
> So, nobody knows which typeclass instance this is, who is talking to > who, or what certain emails were about. Confusion successfully > achieved (: now to grab a coffee and formalise this thread in Agda. > There is no doubt this topic introduces many levels of confusion in my mind! I very much agree with what Shap wrote here: When you call a function, you expect it's behavior to have a sensible > meaning (in the human sense). In practice, this means that either (a) you > supply that meaning explicitly as an argument, or (b) you know what the > meaning is by virtue of shared conventions. -- Case (a) calls for explicit > instances, and I think it's a fine thing for a language to support explicit > instances. Case (b) is the reason that you need a shared understanding of > the rules for automatic instance resolution. I want to recap to be sure I understand the space-of-possibilities correctly... (1) If ordR is lexically/statically scoped in sortR we have no issue (it's not polymorphic in ordR). (2) If ordR is an explicit parameter we have no issue (3) If ordR is a dynamic import of the sortR containing module, we have a run-time bind collision issue when two consumers of sortR wish to use different bindings for ordR. (4) If ordR is bound to the instance, we have either a run-time bind collision issue (if we allow binding ordR onto an existing type) or a flexibility issue (if we don't allow binding ordR onto an existing type). (5) Lastly, if we wish to resolve ordR via some mechanism which is none of the above, we have to define what that mechanism is. I believe I had two co-mingled thoughts about this: (QQ) My first thought appears to be the way Scala handles type-classes (if I understand their system correctly from just reading about it). That is, the use of a type-class creates an implicit parameter to the function. This causes the selection of ordR to be lexically scoped in the *caller*. The compiler automatically supplies this implicit when it can. The same function can also be handed an explicit ordR, which can disambiguate a collision or simply make it explicit in case there is a future collision. Presumably if you wish to defer selection, you must publish your own implicit paramater? (RR) My second thought was to do the same thing, but by way of an implicit *type* parameter instead of an implicit function parameter. A function using an type-class ordR would be implicitly declaring itself parametric in R-with-ordR-specializtion. The caller would have to provide such a type at bind-time, causing a specialization of sortR to be generated based on this type. I can't tell if there is a difference between these two, given sufficient inlining possibilities.. which is why I co-minglined my thoughts about them.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
