On 2014年12月20日 星期六 01:58:43, Jameson Nash <[email protected]> wrote: > 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.
I C. Makes sense. > > 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. Thank you for the advice. Yichao Yu > > 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...
signature.asc
Description: This is a digitally signed message part.
