<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Clément,</div><div><br></div><div>&nbsp; &nbsp; &nbsp;IMO literals should be immutable all the time, and IMO the best way is via a per-object isImmutable bit. &nbsp;We implemented this for VW in 7.0 and it was a positive experience.<br><br>I've implemented the "create an immutable subclass for each literal class" and it has lots of problems (thing printString or storeString having to produce something like 'an immutable string' asMutableString for a normal string).</div><div><br></div><div>The per-object bit has other uses too. &nbsp;Object databases such as GemStone can use it to make write-through scheme efficient. &nbsp;</div><div><br></div><div>The only problem we had was dealing with broken user code that was depending on mutable literals. &nbsp;This is of course a bug, but folks thought we shouldn't just break user code so Alan Knight provided a system setting that write a warning to the transcript and updated the literal instead if raising an error. &nbsp;That's easy to do, if IMO dubious. &nbsp;Fixing the code is as easy as sending copy to the literal in question, the copy being mutable.</div><div><br></div><div>Now I implemented the per-object bit for the Newspeak interpreter WM so you'll find lots of the necessary work is there waiting to be ported to the Stack and Cog VMs. &nbsp;I've not had the time to implement the JIT support to catch inst var and at:put: writes to immutables. &nbsp;But it shouldn't be too much work. &nbsp;Volunteers?</div><div><br></div><div>Eliot (phone)</div><div><br>On Oct 27, 2014, at 8:22 AM, Clément Bera &lt;<a href="mailto:bera.clement@gmail.com">bera.clement@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hey guys,<div><br></div><div>I was discussing about methods like that with Marcus:</div><div><br></div><div><div><font face="courier new, monospace">MyClass&gt;&gt;foo</font></div><div><font face="courier new, monospace"><span class="" style="white-space:pre">        </span>#(false) first&nbsp;</font></div><div><font face="courier new, monospace"><span class="" style="white-space:pre">                </span>ifFalse: [&nbsp;</font></div><div><font face="courier new, monospace"><span class="" style="white-space:pre">                        </span>'first call since compilation' logCr.&nbsp;</font></div><div><font face="courier new, monospace"><span class="" style="white-space:pre">                        </span>#(false) at: 1 put: true ]</font></div><div><font face="courier new, monospace"><span class="" style="white-space:pre">                </span>ifTrue: [ 'other calls' logCr ]</font></div></div><div><br></div><div>DoIt:</div><div><font face="courier new, monospace">4 timesRepeat: [MyClass new foo ]</font><br></div><div><br></div><div>Transcript:</div><div><div><font face="courier new, monospace">'first call since compilation'</font></div><div><font face="courier new, monospace">'other calls'</font></div><div><font face="courier new, monospace">'other calls'</font></div><div><font face="courier new, monospace">'other calls'</font></div></div><div><br></div><div>In the sista image/VM, we are most probably going with Eliot to implement a slow path when you edit the literal of a method (deoptimizing the method) so we can consider that the literals are immutable in the generic case (and if it's not true, execution falls back to a slow path).</div><div><br></div><div>But I was thinking, does it worth it to implement the slow path ?&nbsp;</div><div>Couldn't we just put literals as immutable all the time ?&nbsp;</div><div>The methods as the one shown before would not work any more. But does someone use it ?</div><div><br></div><div>...</div><div><br></div></div>
</div></blockquote></body></html>