On 30/01/2014, at 7:49 PM, srean wrote: > > As o...@pobox.com said to me, > > lazy evaluation IS control flow. And procedural languages are all about > > control flow. > > > > You like saying that, I think that as one of your cases of twisting > > terrmiology. I think everybody gets it that control flow is lazy > > evaluation. Thats considered default, no body, is bothered by it, or > > consider that to be insightful (water is wet, sky is blue etc), because > > when they see a control flow they expect laziness. Thats a non issue. > > Really? I spent 3 DECADES puzzling over this. > Trying to understand "control inversion". > > If you think it is trivial you're obviously a genius. > > That I obviously am....not :) > > Wasn't talking about control inversion but lisp's cond. I think everyone gets > it why cond has to be a special form and cant be eager.
Let try this. With eager evaluation you have a function and some arguments. So you first evaluate the arguments, then the function body. So the arguments consist of .. function evaluations. So you evaluate their arguments and then the functions. After your done, you evaluate the original function body which also consists of function evaluations.. So the picture is: you evaluate the "tree" BOTTOM UP. Draw diagram. Arrows point from leaves to root (for some reason Computer Scientists always live in the Land Down Under and here, roots are at the top and leaves at the bottom .. :) NOTE: when you get to evaluate a parameter, you might just as well plug in the evaluation of the argument into tree. The TIME of evaluation is not relevant. The arguments are not evaluated "first". Its the direction of control flow (master/slave relation) that matters. Now consider lazy evaluation. You immediately enter the function. You see function applications, you immediately evaluate them. When you get to a parameter you evaluate the actual arguments. They're function applications so you evaluate their functions, then the parameters. The leaves in both eager and lazy are constants and variables. So with lazy evaluation you evaluate TOP DOWN. Same tree, arrows reversed. Lazy and eager are DUAL. So now I ask: what is control inversion?? Answer: the application of the duality transform. Swap lazy for eager and vice-versa. So if you consider a master calling a slave (routine calling subroutine) the control inverse reverses the arrow. However we need Einstein and the space-time continuum now. We have to convert flow into memory (i.e. decisions into data and data into flow). How does Felix do this? Simple. instead of the master calling the subroutine (control flow into the subroutine), Felix RETURNS control to the driver. But not just that. It returns something: a continuation. That's the "rest of the program, encapsulated as data". Of course that's a closure. It is the closure of the subroutine. but its not just the closure of the subroutine .. its the closure of the subroutine LINKED to the caller so when the subroutine is finished it RETURNS control to the driver, passing the driver a continuation -- namely the continuation of the master which resumes it where it left off before. So the DOWN arrow of procedure calling control flow is converted to an UP arrow of returning control, and the CODE of the procedure is converted to the DATA of the continuation. That's control inversion, Felix style. -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
