BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Talks.cam//talks.cam.ac.uk//
X-WR-CALNAME:Talks.cam
BEGIN:VEVENT
SUMMARY:Part III projects: Approximating a Haskell stack trace/Language an
 d compiler for heterogenous parallelism - William Kenyon\, Nicholas Tomlin
 son
DTSTART:20130523T120000Z
DTEND:20130523T123000Z
UID:TALK45545@talks.cam.ac.uk
CONTACT:Raoul-Gabriel Urma
DESCRIPTION:These are two 10-minutes practice talks for CST Part III proje
 cts.\n\nTalk 1: W. Kenyon: Approximating a call stack trace in the glasgow
  haskell compiler\n\nTalk 2: N. Tomlinson: A Heterogeneous Parallel Progra
 mming Language and Compiler Architecture\n\nCome along and support/constru
 ctively criticise.\n\nAbstract 1: \nThe 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 T
 RACE in the interactive debugging environment. This is a non-trivial featu
 re to implement. In the context of HASKELL\, it is hard to define what `ca
 ll stack' even means. This is due to HASKELL's LAZINESS and HIGHER ORDERED
 NESS.\n\nWe present an implementation of an "approximate call stack trace"
  feature. It is based on the COST CENTRE STACK technique\, originally intr
 oduced for PROFILING lazy functional programs. A cost centre stack represe
 nts an approximation of what the call stack would be in an imperative lang
 uage. Cost centre stacks have no operational purpose\, debug information i
 s pushed on\, nothing is ever popped off\, and the whole stack may be dump
 ed to screen to give an approximate call stack trace. Cost centre stacks c
 an grow to be very large due to DEEP RECURSION\, therefore CALL STACK COMP
 RESSION is important. We survey existing techniques for call stack compres
 sion\, and introduce a new one. Justifications are made for changes to the
  cost centre stack technique to make it more suitable for approximating ca
 ll stacks. The benefits of our implementation are considered against the o
 verhead introduced. Our considerations include computation time\, memory u
 sage\, and how useful approximate call stacks actually are for debugging r
 eal HASKELL programs.\n\nAbstract 2:\nHow might a programming language be 
 designed that allows the programmer \nto use their intuition about how pro
 grams should be written to write \nparallel programs? How might we design 
 a compiler to compile and \noptimise that language to several different ta
 rgets that interact with \neach other?\n
LOCATION:SW01\, Computer Laboratory\, William Gates Building
END:VEVENT
END:VCALENDAR