[Hat] Possibly incorrect Hat file

[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


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 at haskell.org
> http://www.haskell.org/mailman/listinfo/hat