It's less meaningful to copy a closure because it's unclear what environment those closure variables were intended to come from. You could potentially arrange for the .env field to be copied, however. It's reasonable to copy a lambda (anonymous function), as you are proposing here.
If you're interested in more of the low level pieces of putting a function together, I recommend browsing the base/serialize.jl source code and observe how it passes the Function and LambdaStaticData objects across the wire and reconstructs them on the other end. That should give you an idea of how some of the lower level pieces fit together and how they can be pulled apart and recreated elsewhere. On Fri Dec 19 2014 at 11:04:35 AM Yichao Yu <[email protected]> wrote: > On 2014年12月19日 星期五 15:03:51, Jameson Nash <Julia Users <julia- > [email protected]>> wrote: > > by that same token, the AST itself is not a stable API. what's much more > > likely to change however is the ordering and contents of the fields of > > these, and any type, within Base. > > Speaking of API stability, is there any official compatibility grantee? > I've > seen a thread on the -dev list about it but didn't find any official > statement. > > In general, I'm aware that these API might change in a new version and I'm > fine with it as long as it is still possible to do what I need. I'll also > likely to use LLVM on the remote machine to execute the program and I guess > that has a much higher API breakage rate than julia..... > > > > > .args[2] needs to be regenerated with any changes you've made anyways, so > > it's easiest to just ignore it. you could manually track all of your > > updates in there, and put together a new function object manually, but > it's > > Is it possible to do that? Given that evaluating the AST directly does not > return the function definition itself. (e.g. is it possible to copy the > closure variables as well by just manipulating some AST's?) > > > probably not worthwhile. to be completely safe, I should be checking > > isempty(.args[2][3]), since it's not meaningful to copy a function that > > includes closure variables. > > > > I think it is as meaningful as copying a normal function (which is not very > much in general) but in my case it is probably too complicated to analyse > (at > least for a start).... Thanks for pointing that out... > >
