[gambit-list] set! of local var in compiled code behavior, box-var / var->box

Mikael 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.

Aha, great!

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
> resources?

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.

Yep noted.

> 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.

>  Marc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20111114/1d745109/attachment.html 

More information about the Gambit-list mailing list