Hi guys, I'm not sure, but I think I've found a bug in hat-trans. I have an instance of map being applied to a single element list, however, only one element is ever demanded from the result, so the empty list is never evaluated. This results in these nodes in the hat file (the result pointer of the application of map is 0xa76d): 0xec6: AtomConstructor (Module 0xeb2) position 0:0-0:0, infixr 5, arity=2, : 0xa76d: ExpHidden parent=(Exp 0xa544) result=(Exp 0xa784) children=(ListCons 0xa7c7) ... 0xa77f: ExpForward result=(Exp 0xa76d) 0xa784: ExpValueApp parent=(Exp 0xa76d) fun=(Atom 0xec6) arity=2, args (Exp 0xa77a)(Exp 0xa77f) It makes sense that the result is a hidden node, and as expected the result of that is an application of cons. But look at the result of the cons -- it's the same hidden node as before, shouldn't this point to an unevaluated node? If I try to resurrect an expression from result of map, I get an infinite list, which is obviously rather odd for applying map to a single element list. On the other hand, hat-observe appears to figure out that the list argument of cons is unevaluated, but I can't see exactly what the condition here is that allows hat-observe to tell that this is indeed an unevaluated structure rather than an infinite list. Bob
The trace for execution of trusted code is not well defined and sometimes less useful than desirable, but the situation you describe is correct and intended. As you say, the argument of the cons should be some unevaluated expression. However, that unevaluated expression is from trusted code. No trusted code should appear in the trace and hence we cannot put the unevaluated expression there. We have to put something there and so we simply put the hidden node there. The hidden node already exists in the trace, it is shared, so putting it there doesn't cost any space. We can distinguish this occurrence of the hidden node, because it appears as an argument, a subexpression. So in such a situation a hidden node represents something unevaluated from trusted code and the result is irrelevant. Only when following a result pointer you reach a hidden node, then this is a true hidden node with a valid result. Ciao, Olaf Thomas Davie wrote:
Hi guys, I'm not sure, but I think I've found a bug in hat-trans. I have an instance of map being applied to a single element list, however, only one element is ever demanded from the result, so the empty list is never evaluated. This results in these nodes in the hat file (the result pointer of the application of map is 0xa76d):
0xec6: AtomConstructor (Module 0xeb2) position 0:0-0:0, infixr 5, arity=2, : 0xa76d: ExpHidden parent=(Exp 0xa544) result=(Exp 0xa784) children=(ListCons 0xa7c7) ... 0xa77f: ExpForward result=(Exp 0xa76d) 0xa784: ExpValueApp parent=(Exp 0xa76d) fun=(Atom 0xec6) arity=2, args (Exp 0xa77a)(Exp 0xa77f)
It makes sense that the result is a hidden node, and as expected the result of that is an application of cons. But look at the result of the cons -- it's the same hidden node as before, shouldn't this point to an unevaluated node?
If I try to resurrect an expression from result of map, I get an infinite list, which is obviously rather odd for applying map to a single element list. On the other hand, hat-observe appears to figure out that the list argument of cons is unevaluated, but I can't see exactly what the condition here is that allows hat-observe to tell that this is indeed an unevaluated structure rather than an infinite list.
Bob _______________________________________________ Hat mailing list Hat@haskell.org http://www.haskell.org/mailman/listinfo/hat
participants (2)
-
Olaf Chitil -
Thomas Davie