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