Hi,

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

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

Thanks,
Mikael