On Sat, Feb 21, 2015 at 2:57 AM, 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.
But you've already compiled the HOF. It's now hardwired to call a function natively takes more arguments. To pass a curried function would be unsound. We need to allocate a wrapper. No good. >> And if it's not within the module, you wait till link time? So in >> other words we specialize the HOF to avoid using the subsumption rule? >> You have to admit, that's a pretty weird way to use subtyping. Anyway, >> in that case, it might work, and it might in fact be doing the same >> thing as Shap's version. Since it's so weird, it's not easy for me to >> convince myself that this scheme fully works. > > What? If its outside the module you have to match the exact concrete > imported signature. I though we had already established that everything > worked when all types have concrete arities concrete. I'm not sure what you're saying here. You added a subtyping relation to the fake currying system with its exact arity matching. The type system no longer requires an exact arity match. Your subtyping relation is sound, but it's unacceptable because the coercions allocate. Not accumulators, just the wrappers themselves. If you meant to propose that subtyping wouldn't be used across modules then your proposal is inferior to Shap's since his can specialize across modules at link time. >> Are you saying I did that? You'd better not be. I was only talking >> about subsumptions using _your_ subtyping relation. (Once I reversed >> it to make it work.) > > Reading your comments it seemed like you disagreed with the subtyping > relation (when the correct way round). Apparently you agree :-). Yes, sorry, that was subtle. Your subtyping relation is the one to use, if any. But normally subtyping does its thing via the subsumption rule. However, you can't use the subsumption rule for your subtyping relation because the coercions might allocate. >> Not quite as efficiently, but at least it doesn't allocate. If you >> thought uncurried functions were no faster to fully apply, why did you >> propose specializing definitions to be uncurried in the previous >> email? > > They can be applied as efficiently _because_ you specialise the definition. Well maybe, regarding dual arity specialization, we'll get up to discussing how often it makes to specialize functions to give them uncurried definitions. >> Note that allowing curried and "less-curried" functions to be used by >> the same less-curried application is what Shap's proposal does too. > > Its not clear to me exactly where shap's proposal differs from my > understanding of how this would work. Part of the point in posting was to > discover where the differences are. Superficially at least, the big difference is that Shap's doesn't use subtyping. But I guess you knew that. I'm not clear on exactly which functions get specialized in your proposal, so I can't compare the ultimate effect of your proposal to that of Shap's. Also, you need to agree that you will not use the subsumption rule (which is strange), since the coercions would typically allocate. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
