[gambit-list] set! of local var in compiled code behavior, box-var / var->box
mikael.rcv at gmail.com
Mon Nov 14 14:16:37 EST 2011
You can't disable it. The value returned is the one returned by
> (##set-box! local-var's-box val) which currently returns local-var's-box.
> Note that (set! local-var val) does not allocate a new box, it just
> returns the one that is associated with the local-var.
Great that you clarified this, I didn't get this when testing here.
So basically what happens on the compiled side when creating a local
variable, is that the space for its slot is allocated, and a box is created
that represents it (i.e. the box' slot _is_ the local variable's slot), and
then on any set! to the l.v., the [one and the same] box is returned [every
time] - this is really fine indeed.
Is the issue that you didn't expect this or that you think it uses up
I got the impression that the box allocation was done on a per- set!
invocation -basis - which would mean resource consumption and GC load for
each set! done - though I'm clear it's not now - set! indeed converts into
a MOV [variable slot memory address],[uint representation of new object
reference] assembly instruction, which is great, so it's completely fine.
In compiled code, the box object *is* necessary due to the use of
> assignment conversion for the correct implementation of closures.
If you feel like describing this (use of assignment conversion for the
correct implementation of closures) concept a bit, please feel free to do
I think you dislike that (set! local-var val) returns the box object
> associated with the local-var, but I am not sure why?
set! returning anything is fine with me.
Note that in Scheme the value returned by (set! var val) is unspecified, so
> Gambit's behaviour conforms to the spec.
> It would be great to have this feature as a separate primitive instead,
> like box-var or var->box or sth, that'd work for both in interpreted and
> compiled code, and both for local and global vars. If there's anything like
> this, please let me/the ml know.
> The interpreter uses another representation for local variables. They are
> part of a frame which is represented with a vector.
Aha. If it making these [vector element slots] boxable would be piece of
cake and doable without any addition of complexity to the scheme system
it'd be a cool and probably useful feature, though it's completely outside
of the conventional scheme way so completely not worth it otherwise.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list