[Hat] Possibly incorrect Hat file

[Thomas Davie]

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

[Olaf Chitil]

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

Post by Thomas Davie
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
0xec6: AtomConstructor (Module 0xeb2) position 0:0-0:0,
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
http://www.haskell.org/mailman/listinfo/hat