I am still interested in discussing dual arity specialization, in case anyone forgot with all the noise.
In one of the less unproductive parts of that noise, I introduced new terms that could be helpful: Definition-driven specialization: This is what Shap proposed, as I understand it. Definitions have a concrete arity. Applications are arity-abstract, and can be specialized. Application-driven specialization: The "dual" of definition-driven. Applications require a certain concrete arity. Definitions are arity-abstract, and can be specialized. On Fri, Feb 20, 2015 at 4:24 PM, Matt Oliveri <[email protected]> wrote: > My other question has to do with the decision that function > definitions always have a concrete arity. Keean seems very interested > in doing something dual, where applications have a concrete arity, and > definitions are specialized to work for their applications. There is > also the a-priori possibility of combining them, using some other kind > of rule to pick the concrete arity. But do these alternatives actually > work? > > The original reason I was suspicious of definitions always being > concrete was an example that looked kind of funny that way: > > passArith f = f (\x y -> x + y) (\x y -> x - y) > passArith : fn ((fn Nat Nat -> Nat)->(fn Nat Nat -> Nat)->Nat) -> Nat > > So this function has a concrete arity, its parameter is > arity-abstract, and its parameter's parameters have a concrete arity. > This seemed weird. However, it seems to work: > > useArith plus minus = minus 10 (plus 4 3) > useArith : fn (Nat->Nat->'a) (Nat->'a->'b) -> 'b > > useArith' plus = lambda minus = minus 10 (plus 4 3) > useArith' : fn (Nat->Nat->'a) -> fn (Nat->'a->'b) -> 'b > > These functions have alternative concrete arities, and their > parameters are all arity-abstract. I picked them because, ignoring > native arity, they can be passed to passArith. And indeed, they _can_ > be passed to passArith; all the abstract arities work out. The > useAriths are specialized with 2-applications, and we get passArith > specializations for both useArith arities. > > Since your scheme worked better than I expected here, I figure you > should be the one to explain the reason for concrete definitions, and > perhaps reasons against other schemes. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
