Hi,<br><br><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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.  </blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Note that (set! local-var val) does not allocate a new
 box, it just returns the one that is associated with the local-var.<br></blockquote><div> <br>Aha, great!<br><br>Great that you clarified this, I didn't get this when testing here.<br><br>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.<br>

<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">  Is the issue that you didn't expect this or that you think it uses up resources?  </blockquote>


<br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
In compiled code, the box object *is* necessary due to the use of 
assignment conversion for the correct implementation of closures.  </blockquote><br>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.<br>

<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I think you dislike that (set! local-var val) returns the box object associated with the local-var, but I am not sure why? </blockquote>

 <br>set! returning anything is fine with me.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Note that in Scheme the value returned by (set! var val) is unspecified, so Gambit's behaviour conforms to the spec.<br>

</blockquote><div><br>Yep noted.<br><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> 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.<br>


<br>
</div>The interpreter uses another representation for local variables.  They are part of a frame which is represented with a vector.<br></blockquote><div><br>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.<br>

 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<font color="#888888">
Marc<br>
</font></blockquote></div><br>Thanks,<br>Mikael<br><br>