Re: Possibly incorrect Hat file

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
> Hathaskell.org
> http://ww
w.haskell.org/mailman/listinfo/hat


_______________________________________________
Hat mailing list
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat