@mflatt We’re tyring to utilize the import-keys and get-import arguments to compile-linklet on Pycket. The docs say that the returned instance represents an instance to be provided to the compiled linklet when it is eventually instantiated. We’re unclear about that relationship between the two instances. I observe on Pycket that they’re not the “same” instance (e.g. for a particular id, the instance that the get-import returns does have the variable but with a different value than the instance provided at the instantiation). It is also possible that we are doing something wrong on Pycket that causes an inconsistency, therefore it would really help if you can tell us a bit about what information that the instance from get-import provides, and the relationship between the two instances (the one that the callback returns and the one that’s eventually provided to the instantiation). Thanks!

The instance or linklet returned by get-import is a conservative approximation to the instance that will be supplied at run time. In the case of a linklet, it will be one of the linklets that your compile-linklet produced before, and the instance at runtime will instantiate that linklet. In the case of an instance returned by get-import, it is a conservative approximation of the run-time instance; any binding in the instance will be present at run time, and anything marked as “consistent” will have a value with the same shape at run time, and so on – but a variable not marked as “consistent” may have a different value at run time. But the cases where get-import returns an instance are generally only for instances that are synthesized by the expander, anyway. Unless I misremember, you shouldn’t get an instance from get-import that corresponds to a linklet that your compiled-linklet generates.

@mflatt Thanks for explanation! That makes sense. The example that I was talking about above was about the identifier syntax-literals, which is initially reported in a linklet-instance named top-syntax-literals by the get-import (which is as you stated something that the expander creates), and then it is provided in a link instance at run time, with a different value, but the variable was marked as a constant.

In case it’s not clear, since the terminology is not great: “constant” means “won’t change anymore in this instance” — as opposed to the stronger “consistent”.

@mflatt Ah I see, that made it more clear, thanks! So then a “consistent” variable means that it’s value technically may change but it will always have the same shape (across all the instances), is that accurate?

Yes, it may change across instances (but is the same as “constant” within an instance), while all instances will have the same shape for the value.

@mflatt Ok, that clears it a lot, thanks!