Stefan O'Rear wrote:
I'm sorry, I seem to have horribly mangled my question. in the present
implementation:
ptr1 -----> Some Big
ptr2 -----> Full PAP
after EVAL:
/-----------\
ptr1 -----/ An Ind- \--V
ptr2 -----> irection ---> Value
after POP_1:
An Ind-
ptr1 -----> irection ---> Value
INT_SWITCH examines Value.
In the implementation I'm trying for, INT_SWITCH would examine the
indirection, BUT in my implentation EVAL *does* chase indirections,
so:
g(ptr1,ptr2) = ptr1 `seq` ptr2
ptr1 -----> Some Big
ptr2 -----> Full PAP
after EVAL:
/-----------\
ptr1 -----/ An Ind- \--V
ptr2 -----> irection ---> Value
after POP_1:
An Ind-
ptr1 -----> irection ---> Value
after EVAL: (chases the ind):
An Ind-
ptr1 ---\ irection /-> Value
\------------/
which is returned. (yes I know about RETURN_EVAL)
I'm affraid I'm still slightly unclear on your question. In the current
implementation:
g(ptr1,ptr2) = ptr1 `seq` ptr2
Is compiled into something approximating
g(ptr1,ptr2):
PUSH_ZAP_ARG ptr1
EVAL
POP_1
PUSH_ZAP_ARG ptr2
RETURN_EVAL
Executing this we would get something like
g(ptr1,ptr2):
ptr1 ---> Some Big Thunk
ptr2 ----------^
PUSH_ZAP_ARG ptr1
ptr1 ---------> ZAP
ptr2 ---------> Some Big thunk
EVAL
// eval doesn't remove indirections from the result
ptr2 ---> Ind ------> Value
POP_1
ptr2 ---> Ind ------> Value
PUSH_ZAP_ARG ptr2
ptr2 ---> ZAP
RETURN_EVAL
// return_eval must eventually finish with 'return',
// and 'return' doesn't remove indirections so the result
// of g will have an indirection in it.
It would certainly be possible to make RETURN remove indirections from
the result - and it might constitute a small optimization.
Known, known, known.
Appologies, your question seemed to be asking "why do we need
indirections?", though it's clear now that's not what you mean :-)
Am doing so since about a week ago :)
Ah excellent :-)
Tom
_______________________________________________
Yhc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/yhc
