On 05/03/2014, at 5:40 AM, srean wrote: > OK, so is that what you use to get the conventional lexical closure: define > the function 'noinline' ? Alternatively, will declaring the captured variable > 'var' be sufficient ? I guess not.
It IS a conventional closure. The problem is with an arity 2 function, you don't normally GET a closure for the first application. Watch this: fun f (x:int) (y:int) => x + y; var a : (int -> int)^5; for var i in 0 upto 4 do var k = i; var g = f; // <<------------------------------------ a.i = g k; ++k; done var y = 100; for i in 0 upto 4 do println$ a.i y; done ~/felix>build/release/host/bin/flx --test=build/release ac 100 101 102 103 104 See? Now I used another method to force a closure to be formed from f. We apply the closure to form another one, in a.i. Now it works as expected because the x parameter is a an argument of the closure. I suggested noinline last email .. I admit I didn't even think of the above then. The issue here has nothing to do with the "kind" of closure. It has to do with the scope over which the closure closes. Felix loops don't create new scopes on the heap. Ocaml does: a for loop in Ocaml is an abbreviation for tail recursion. So when Felix inlines, the body of the code AND all its children are "reseated" into the parent. This includes variables. Actually I call it cloning in the comments in the compiler. If you do two calls to the same function, its parameter, call it p, is cloned twice to say p1, and p2. Just as the body is inserted twice. But this is only static. It doesn't make N copies of p when the call is inside a loop going N times. So roughly, it has to work this way. There's no other way to do it. There are choices, such as when to make new scopes. Felix already choses the loops etc are flat: no new scopes. It also inlines aggressively and this sometimes leads to unexpected behaviour. There are tools to stop this. Inlining in Felix is not transparent. It does change behaviour. I agree this is tricky, which is why I keep posting examples of it when I get caught myself. I'd like to find a way to fix this but I don't know of a good one at the moment. -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
