[Nix-dev] maximal sharing and comparisons.

Nicolas Pierron nicolas.b.pierron at gmail.com
Sun Nov 30 01:44:23 CET 2008


On Sun, Nov 30, 2008 at 00:43, Marc Weber <marco-oweber at gmx.de> wrote:
>> So, the evaluation of the following expression:
>>
>> (__trace "bad" (__trace "good" 1)) == (__trace "bad" 1)
>>
>> should only print "good" and not "bad".  If we admit the previous
>> example to be correct, how should we consider this one:
>>
>> let
>>   tkFirst = f: s: __trace "bad tkFirst" f; /* ignore s */
>> in
>>   (tkFirst (__trace "good" 1) (__trace "bad args" 0)) == (tkFirst 1 0)
>              ^^^^^^^^^^^^^^^    ^^^^^^^^^^^^^^^^^^^
                                  ^^^^^^^^^^^^^^^^^^^
> of course these two have to be evaluated.

I disagree, the second one should not be evaluated because it is not used.

> How else should nix know that
> it compares tkFirst 1 0 with tkFirst 1 0? It can only know so if the
> internal representation is the same which won't be the case unlress both
> __trace functions have been evaluated. Of course nix doesn't have to
> evaluate tkFirst then on either side.
> At least this is the best behaviour I can think of.

My idea was in the opposite way with the following desugar steps:

(tkFirst (__trace "good" 1) (__trace "bad args" 0)) == (tkFirst 1 0)
--> strict equal ? (__trace "good" 1) == 1 && (__trace "bad args" 0) =
0 --> false
((f: s: __trace "bad tkFirst" f) (__trace "good" 1) (__trace "bad
args" 0)) == ((f: s: __trace "bad tkFirst" f) 1 0)
((s: __trace "bad tkFirst" (__trace "good" 1)) (__trace "bad args" 0))
== ((s: __trace "bad tkFirst" 1) 0)
(__trace "bad tkFirst" (__trace "good" 1)) == (__trace "bad tkFirst" 1)
--> usual equal ? "bad tkFirst" == "bad tkFirst" && (__trace "good" 1) == 1
--> display "good"

We have to compare argument in a strict way because we don't know what
the function is doing with them and we are not allowed to evaluate
them in order to respect the laziness concept.  Howerver, the __trace
function is well know and both arguments will be evaluated in every
cases.  So, there is no issue against the evaluation of the arguments.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron
- If you are doing something twice then you should try to do it once.



More information about the nix-dev mailing list