Part III projects: Approximating a Haskell stack trace/Language and compiler for heterogenous parallelism
- đ¤ Speaker: William Kenyon, Nicholas Tomlinson
- đ Date & Time: Thursday 23 May 2013, 13:00 - 13:30
- đ Venue: SW01, Computer Laboratory, William Gates Building
Abstract
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?
Series This talk is part of the Computer Laboratory Programming Research Group Seminar series.
Included in Lists
- All Talks (aka the CURE list)
- bld31
- Cambridge talks
- Computer Laboratory Programming Research Group Seminar
- Department of Computer Science and Technology talks and seminars
- Interested Talks
- School of Technology
- SW01, Computer Laboratory, William Gates Building
- Trust & Technology Initiative - interesting events
- yk449
Note: Ex-directory lists are not shown.
![[Talks.cam]](/static/images/talkslogosmall.gif)

William Kenyon, Nicholas Tomlinson
Thursday 23 May 2013, 13:00-13:30