<div dir="ltr"><font color="#003333"><font size="2"><font face="trebuchet ms,sans-serif">My previous two messages suggest a Haskell coding principle: distinguish between fixed and (quasi-)mutable data structures. (I know values don&#39;t change, but I hope you understand what I mean. The cage and the cell in my previous example are quasi-mutable. They are conceptually mutable in the context of the problem.)  The fixed data structures can be organized any way one wants. The quasi-/conceptually-mutable elements should be referred to symbolically and stored in a Map. The maps themselves should be stored at a global level of the system&#39;s data structure so that it is easy to replace them when values change.<br clear="all">

</font></font></font><div dir="ltr"><font><font face="&#39;trebuchet ms&#39;, sans-serif"><i><font color="#003333"><br>-- Russ </font></i></font></font></div><br>
<br><br><div class="gmail_quote">On Wed, Nov 24, 2010 at 5:54 PM, Russ Abbott <span dir="ltr">&lt;<a href="mailto:russ.abbott@gmail.com">russ.abbott@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div dir="ltr"><font color="#003333"><font size="2"><font face="trebuchet ms,sans-serif">Actually using a Map does solve the problem. The Map has to be kept at the level of the Tree rather than have each leaf node point to it.  So instead of just a Tree one has, say (Map, Tree). Then when one wants to change the property of something associated with a leaf node, one can just change the map. The Tree is unchanged.<br clear="all">


</font></font></font><div dir="ltr"><font><font face="&#39;trebuchet ms&#39;, sans-serif"><i><font color="#003333"><br>-- Russ</font></i></font></font></div><div><div></div><div class="h5"><div dir="ltr"><font><i></i></font><font color="#003333" face="&#39;trebuchet ms&#39;, sans-serif"><i><br>


</i></font><div><font><font face="&#39;trebuchet ms&#39;, sans-serif"><i><font color="#003333"></font></i></font><br></font></div></div>
<br><br><div class="gmail_quote">On Wed, Nov 24, 2010 at 2:02 PM, Russ Abbott <span dir="ltr">&lt;<a href="mailto:russ.abbott@gmail.com" target="_blank">russ.abbott@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr"><font color="#003333"><font size="2"><font face="trebuchet ms,sans-serif">OK. So putting a Map at Leaf nodes doesn&#39;t solve the problem.   (Apparently I haven&#39;t been able to communicate what I see as the problem.)</font></font></font><div>



<font color="#003333" face="&#39;trebuchet ms&#39;, sans-serif"><br></font></div><div><font size="2"></font><font color="#003333" face="&#39;trebuchet ms&#39;, sans-serif">The problem that I&#39;m trying to get to is the need to write excessive code for something that would require a lot less code in an OO world.  It&#39;s not a matter of execution time or space. It&#39;s a matter of the amount of code one is required to write.</font></div>



<div><div><div dir="ltr"><font><font face="&#39;trebuchet ms&#39;, sans-serif"><i><font color="#003333"><br><font color="#888888">-- Russ </font></font></i></font></font></div><div><div></div><div><br>
<br><br><div class="gmail_quote">On Wed, Nov 24, 2010 at 1:52 PM, Daniel Fischer <span dir="ltr">&lt;<a href="mailto:daniel.is.fischer@web.de" target="_blank">daniel.is.fischer@web.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>On Wednesday 24 November 2010 22:12:37, Russ Abbott wrote:<br>
&gt; Cool. I wasn&#39;t aware of that notation.  It doesn&#39;t quite get to the<br>
&gt; issue though.<br>
&gt;<br>
&gt; The problem I&#39;m concerned about is the need to define y in the first<br>
&gt; place. If one is chasing through a data structure and finds a need to<br>
&gt; change something buried within it, it seems necessary to rebuild<br>
&gt; everything that includes the changed thing.<br>
<br>
</div>In general, values are immutable, so you can&#39;t &quot;change something buried<br>
within it&quot;. You have to build a new value containing some of the old stuff<br>
and a new part. Building the new value usually consists mostly of copying a<br>
couple of pointers (plus building the new part of course), so isn&#39;t too<br>
expensive normally.<br>
<br>
You can have mutable values in the IO or (ST s) monads, if you need them.<br>
<div><br>
&gt; That is, I can&#39;t change a<br>
&gt; component of somethingNew without creating y. The point is there&#39;s<br>
&gt; nothing about x that changed,<br>
<br>
</div>The thing with the changed component is not x anymore.<br>
<div><br>
&gt; and there may be nothing about (var1 x)<br>
&gt; that changed, and there may be nothing about var11 . var1 $ x that<br>
&gt; changed, etc. Yet one is apparently forced to keep track of and<br>
&gt; reconstruct all those elements.<br>
<br>
</div>The compiler takes care of that.<br>
<div><br>
&gt;<br>
&gt; Another example is to imagine a Tree in which the leaves contain<br>
&gt; &quot;objects.&quot; If I want to change a property of one of those leaf objects,<br>
<br>
</div>You can&#39;t in general, the thing with a different property is a different<br>
object.<br>
<div><br>
&gt; I am forced to rebuild all the ancestor nodes of that leaf down to<br>
&gt; rebuilding the root.<br>
<br>
</div>Yes (well, not you, the compiler does it), except if your tree contains<br>
mutable objects (IORefs/STRefs for example).<br>
<div><br>
&gt;<br>
&gt; One way to avoid that is for the leaves to refer to their objects<br>
&gt; through a Map. Then changing a leaf object requires only that the value<br>
&gt; associated with key represented by the leaf be (re-)inserted into the<br>
&gt; Map.  The Tree itself need not change at all.<br>
<br>
</div>Oh, it will. If you change a Map, you get a new one, thus you get a new<br>
tree containing the new Map.<br>
<div><br>
&gt;<br>
&gt; But that trick isn&#39;t always available.  In the example we are talking<br>
&gt; about we can&#39;t make a Map where they keys are the instance variable<br>
&gt; names and the values are their values.  That would seem to do the job,<br>
&gt; but since the values are of different types, we can&#39;t create such a Map.<br>
&gt;<br>
&gt; So now what?<br>
<br>
</div>Well, what&#39;s the problem with the compiler copying some nodes?<br>
Normally, that doesn&#39;t cost very much performance, if it does in your case,<br>
we&#39;d need to know more to suggest the best way to go.<br>
<br>
&gt; *<br>
&gt; -- Russ *<br>
&gt;<br>
</blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>