On Sat, Feb 21, 2015 at 3:36 AM, Keean Schupke <[email protected]> wrote: > > On 21 Feb 2015 07:57, "Keean Schupke" <[email protected]> wrote: >> >> >>> And then what happens when you call the HOF with a function that's a >>> subtype of the one it expects? >> >> >> Thats okay because you can always call with more arguments. >> > > I think my explanation is wrong :-) its not that you can call with more > arguments, which is wrong because you will have less arguments when it is > applied.
No that part wasn't wrong. The HOF will call its argument with more arguments than it requires. > It that the application defines the concrete type so we specialise the > higher order function according to the type passed, and this is always > making is less curried. You mean it makes the applications in the HOF less curried? Yes, this is what I originally thought you intended. To specialize. But again, normally one doesn't use avoiding the subsumption rule of subtyping as a specialization mechanism. At least I've never heard of that. > If the HOF is imported the function argument can be specialised to match the > required concrete type. This is not necessary. We can specialize at link time. Specializing the argument instead would be dual arity specialization. This isn't necessarily bad, but I wish you had made it clear up front that your proposal relies heavily on changing the arity of both lambdas and applications, since that is a major difference from Shap's proposal, which only changes applications. > If the function argument is imported the HOF is specialised to match the > argument arity. > > If both are imported the concrete arities must match. Keean, are you making this up as you go along? I don't think you ever said anything about all these cases. Anyway, this still doesn't tell us what to do with abstract (we don't know where it came from) HOFs and function arguments. Shap's scheme doesn't have cases like this. We know what functions need to be specialized from their type. > Hopefully that explains it better. I posted a typing for your example a few > posts back that is probably better than my attempts to explain it. It's a little better, if you stick to it. But it still seems awfully hand-wavy. An implicit advantage of Shap's specialization proposal is that it's similar to the specialization to handle generics, which is already understood. Your proposal somehow uses "subtyping" to trigger specialization, which you simply came up with yourself AFAIK. You have more explaining to do than Shap, but it feels like you've done less explaining. It's clear from what you said now that your proposal is truly different from Shap's. So that answers your question. Now my question is: What do you think are its advantages and disadvantages. This will give people perspective about your decisions. (Or allow them to reject it out of hand.) As far as the example, I did not break the code there across modules since that's not what confuses me about Shap's proposal. But with your proposal, the examples you should give are the various cases of specialization which apparently hinge on where the functions come from. Cards on the table: While I think it might be a good idea to use both Shap's "definition-driven" arity specialization, and your "application-driven" dual specialization, and your order on types seems informally useful, I really don't think subtyping is the way to do this. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
