On Thu, Jan 8, 2009 at 1:49 AM, minh thu <span dir="ltr">&lt;<a href="mailto:noteed@gmail.com">noteed@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I&#39;d like to simply write, like above,<br>
<div class="Ih2E3d"><br>
b = B a a where a = A [C]<br>
<br>
</div>or, maybe,<br>
<br>
b = B label a a where a = A label [C]<br>
<br>
The question is : how can label be different each time ?</blockquote><div><br>Haskell is pure, so I can answer this precisely:&nbsp; obviously you cannot.&nbsp; Sharing is <i>not</i> observable in Haskell, because it breaks referential transparency, a very important property.<br>
<br>So what I meant by hashing was, eg.:<br><br>&nbsp; newtype Hash = ...<br>&nbsp; data Foo = Foo Hash Int [Foo]<br></div></div><br>&nbsp; mkFoo :: Int -&gt; [Foo] -&gt; Foo<br>&nbsp; mkFoo n xs = Foo (hash (show n ++ concatMap (\(Foo h _ _) -&gt; show h))) n xs<br>
&nbsp; <br>&nbsp; hash :: String -&gt; Hash<br>&nbsp; hash = ... -- some cryptographic hash function<br><br>Probably going through Strings is not the smartest way, but you get the idea?<br><br>Then when two Foos have the same hash, you have odds of 1/2^64 or whatever that they are the same object.&nbsp; You could also compare directly without hashes, but that is slower for large data structures (more correct though -- hash comparisons always gave me the creeps).<br>
<br>I just saw your reply to the StableName suggestion.&nbsp; I should warn you -- you should use this information only for optimization internal to your program.&nbsp; If you use it for observable effects, e.g. generating code or writing to a file[1], you are writing <i>bad haskell</i>, and you will not only lose the benefits of Haskell&#39;s purity, but you will be bitten by the unpredictable zeal of the optimizer.<br>
<br>Luke<br><br>[1] Unless you read the file back into the data structure, where the sharing is once again not observable.<br>