> 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. > 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. > 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 :-). > 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. > > 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. > Constraining what function? (fn 'a 'a -> 'a)? It makes no sense to > constrain that, since it's already a concrete function type. Type class constraints also indicate membership, so it is an instance of "Arity 2", even if it is not necessary, it is not wrong for it to be a member. > I think there's been a misunderstanding. There's no such thing as an > abstract arity. Shap's proposal uses arity-abstract types, which have > had the (concrete) arity abstracted out of them. > There is obviously such a thing as we can sum all the components of an arity as in: (1, 1, 1) = Arity 3 (2, 1) = Arity 3 (1, 2) = Arity 3 (3) = Arity 3 In any case, abstract-arty types that have the arity abstracted out do not represent the same thing as a subtyping hierarchy with fully-curried as the super type. > In Shap's proposal this is a unification error. (f 1) constrains the > type of f to have an arity of at most 1. I currently don't understand > the details of the notation, so I don't know how you'd read that > constraint from a type, but here we can infer it. But f has arity 2. > Okay so there is no difference here. We both think it should return be a type error. > > The other way around, applying more arguments to a curried function is > > trivial to see requires no additional allocations. > > Right, and Shap's proposal is designed to allow that. > Without a subtype hierarchy, I don't see how the abstract-arity type only admits less-curried applications? Is there some kind of implicit subtype hierarchy? Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
