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
_______________________________________________
Hat mailing list
Hat@...
http://www.haskell.org/mailman/listinfo/hat

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

_______________________________________________
Hat mailing list
Hat@...
http://www.haskell.org/mailman/listinfo/hat