samth
2018-3-14 18:07:27

@mflatt another question from me and @cadr: (define l140-inst (instantiate-linklet (compile-linklet '(linklet () (x) (define-values (x) 4))) null)) (define l141 (compile-linklet '(linklet ((x)) (g) (define-values (g) (lambda (y) x))))) (define targ140 (make-instance #f #f #f)) (define result140 (instantiate-linklet l141 (list l140-inst) targ140)) (check-satisfied 'g (in? (instance-variable-names targ140)))

after this code, x is not in the instance-variable-names of targ140, but that instance does remember the value, so that for example this call works: (define l142 (compile-linklet '(linklet () (g) (g 5)))) (define result141 (instantiate-linklet l142 null targ140)) Is the represented with x as a lexical variable in the closure of g, or does targ140 store it somewhere (and if so, where in the C structure for Scheme_Instance is that)?

(note that in the cs version, x is in the closure of the procedure implementing the instance)


mflatt
2018-3-14 19:25:40

instance-variable-names reports variable defined in the linklet/instance, not variables that are imported from other instances, so that’s why x would not be included for targ140.

Yes, x is in the closure of the value of g. For that matter, if the value of g referred to any variable defined within the same linklet, the variable would be in the closure. The value of g does not refer (strongly) back to the instance, and that’s important for space safety.


samth
2018-3-14 21:28:48

@cadr I think that means we should do the same, and hold references to linklet variables in the closure


cadr
2018-3-14 22:16:12

@samth you mean getting all the variables available at the closure creation and putting them into the environment that it captures, rather than just putting in there the instance that contains the closure


samth
2018-3-14 22:16:48

I mean saving those variables in the closure the same way we save lexical variables


cadr
2018-3-14 22:16:49

@samth or do you mean the imported variable x (exported by the l140-inst above) to be the exact same object (LinkletVar) with the one inside the closure and importing it will modify its value so the resolution is no longer a problem, which could be problematic to do at the compilation ?


samth
2018-3-14 22:21:25

I don’t understand what that means


samth
2018-3-14 22:22:32

I mean that (lambda () y) where y is a linklet-bound variable should have an entry for y in the closure, which should be mutable if it’s a mutable linklet variable


cadr
2018-3-14 22:32:40

Currently we’re putting the instance (that has the closure) in the environment that the closure captures and lookup any variables through that instance, because the assumption was that all the variables for the closure will be available in that instance, which is sadly not true for the imported variables. So i understand you suggest, instead of putting the instance we should get all the available variables (which will include the imported ones) at the time of closure creation and put them into the environment like the lexical variables, is that accurate?


samth
2018-3-14 22:44:59

@cadr yes, except it should only be referenced variables (which is what happens for lexical variables too)


cadr
2018-3-14 22:47:07

@samth ok got it, thanks!