University of Cambridge > > Computer Laboratory Programming Research Group Seminar > Part III projects: Approximating a Haskell stack trace/Language and compiler for heterogenous parallelism

Part III projects: Approximating a Haskell stack trace/Language and compiler for heterogenous parallelism

Add to your list(s) Download to your calendar using vCal

If you have a question about this talk, please contact Raoul-Gabriel Urma.

These are two 10-minutes practice talks for CST Part III projects.

Talk 1: W. Kenyon: Approximating a call stack trace in the glasgow haskell compiler

Talk 2: N. Tomlinson: A Heterogeneous Parallel Programming Language and Compiler Architecture

Come along and support/constructively criticise.

Abstract 1: The GLASGOW HASKELL COMPILER (GHC) is an industrial strength compiler and interactive debugging environment for HASKELL . A common complaint is that there is no way to view a CALL STACK TRACE in the interactive debugging environment. This is a non-trivial feature to implement. In the context of HASKELL , it is hard to define what `call stack’ even means. This is due to HASKELL ’s LAZINESS and HIGHER ORDEREDNESS .

We present an implementation of an “approximate call stack trace” feature. It is based on the COST CENTRE STACK technique, originally introduced for PROFILING lazy functional programs. A cost centre stack represents an approximation of what the call stack would be in an imperative language. Cost centre stacks have no operational purpose, debug information is pushed on, nothing is ever popped off, and the whole stack may be dumped to screen to give an approximate call stack trace. Cost centre stacks can grow to be very large due to DEEP RECURSION , therefore CALL STACK COMPRESSION is important. We survey existing techniques for call stack compression, and introduce a new one. Justifications are made for changes to the cost centre stack technique to make it more suitable for approximating call stacks. The benefits of our implementation are considered against the overhead introduced. Our considerations include computation time, memory usage, and how useful approximate call stacks actually are for debugging real HASKELL programs.

Abstract 2: How might a programming language be designed that allows the programmer to use their intuition about how programs should be written to write parallel programs? How might we design a compiler to compile and optimise that language to several different targets that interact with each other?

This talk is part of the Computer Laboratory Programming Research Group Seminar series.

Tell a friend about this talk:

This talk is included in these lists:

Note that ex-directory lists are not shown.


© 2006-2019, University of Cambridge. Contact Us | Help and Documentation | Privacy and Publicity