
Hello, When I compile a program that contains a lambda, the compiler assigns it a name like LAMBDA245. Is there any simple way to retrieve the body of the lambda, in an automated way, perhaps by modifying the compiler? I'm building a tracer/debugger that shows the structure of the heap, using a redex trail-like data structure, and it describes indirections in the heap well, except when lambdas are involved. In the latter case, the compiler-generated names obviously mean nothing to the user and don't help him identify which of the lambdas in the code was evaluated. Is there any easy way to map the name of the lambda to its body (as Haskell source, not bytecode) without doing a source-to-source transformation? Thanks. -Kartik -- Blogs: http://kartik-log.blogspot.com, http://randomkart.blogspot.com

On Fri, Jun 22, 2007 at 01:12:33PM +0530, Kartik Vaddadi wrote:
Hello, When I compile a program that contains a lambda, the compiler assigns it a name like LAMBDA245. Is there any simple way to retrieve the body of the lambda, in an automated way, perhaps by modifying the compiler?
I'm building a tracer/debugger that shows the structure of the heap, using a redex trail-like data structure, and it describes indirections in the heap well, except when lambdas are involved. In the latter case, the compiler-generated names obviously mean nothing to the user and don't help him identify which of the lambdas in the code was evaluated. Is there any easy way to map the name of the lambda to its body (as Haskell source, not bytecode) without doing a source-to-source transformation? Thanks.
I started a project exactly like that a few months ago (stagnant for reasons that don't affect you at all); while reading Simon Marlow's publications list earlier today, I stumbled on an interesting reference - Freja, the first of the Haskell debuggers, operated in exactly this way, using an instrumented GHC (maybe it was HBC? the paper didn't say) runtime system. Might be worth checking out. I think it would be a good idea for Yhc to generate lambda names using an encoded form of the token location. Stefan

Stefan O'Rear
I'm building a tracer/debugger that shows the structure of the heap, using a redex trail-like data structure,
- Freja, the first of the Haskell debuggers, operated in exactly this way, using an instrumented GHC (maybe it was HBC? the paper didn't say) runtime system.
Actually, Freja had its own nearly-complete compiler for Haskell. We tried to persuade Henrik to release it more widely as "hhc" (hardly a haskell compiler), but he did not have enough time to support it properly. Freja/hhc was a native code compiler (sparc only). It was the first Haskell compiler to deal properly with mutually recursive modules (you could include many modules into a single source file). The more serious deficiency was a lack of typeclasses (but I believe Henrik fixed that in later versions). Regards, Malcolm

Hi Kartik,
Tom was going to give a go at implementing this a month ago, I'm not
sure if he got anywhere - I'll ask him. This would be useful for
various other Yhc.Core tools as well.
Thanks
Neil
On 6/22/07, Kartik Vaddadi
Hello, When I compile a program that contains a lambda, the compiler assigns it a name like LAMBDA245. Is there any simple way to retrieve the body of the lambda, in an automated way, perhaps by modifying the compiler?
I'm building a tracer/debugger that shows the structure of the heap, using a redex trail-like data structure, and it describes indirections in the heap well, except when lambdas are involved. In the latter case, the compiler-generated names obviously mean nothing to the user and don't help him identify which of the lambdas in the code was evaluated. Is there any easy way to map the name of the lambda to its body (as Haskell source, not bytecode) without doing a source-to-source transformation? Thanks.
-Kartik -- Blogs: http://kartik-log.blogspot.com, http://randomkart.blogspot.com
_______________________________________________ Yhc mailing list Yhc@haskell.org http://www.haskell.org/mailman/listinfo/yhc
participants (4)
-
Kartik Vaddadi
-
Malcolm Wallace
-
Neil Mitchell
-
Stefan O'Rear