TRIP REPORTS FROM PLI 2000 ART Memo 11 (Version 1) Olaf Chitil, Colin Runciman 7 October 2000 INTRODUCTION We all went to PLI 2000. In this memo, Olaf reports on the Haskell Workshop, Malcolm on ICFP (the biggest conference) and Colin on the side-discussions about tracing. THE HASKELL WORKSHOP The fourth Haskell workshop took place on the 17th September 2000. With about 60 registered participants and up to 90 persons actually attending, it had a large group of interested participants. Most talks caused lively subsequent discussion. Erik Meijer: Lambada, Haskell as a Better Java The talk was actually more about compiling Haskell to Java and compiling Haskell to the new Microsoft .NET platform. I have the impression that Erik Meijer initiates lots of projects related to using Haskell for e-commerce, but each project only leads to a paper describing how the new software is used, and the project dies (followed by a new project), before many people actually use the new software. The papers also do not give much new insight into interesting technical solutions. Simon Marlow: Writing High-Performance Server Applications in Haskell Demonstrates that a real application can be implemented in short time by a short Haskell program. Simon says that it still needs a bit of polishing to be used for haskell.org. Also, it does not suppose CGI at the moment. The server also demonstrates the usefulness/necessity of concurrency and exceptions in GHC (see SimonPJ's Marktoberdorf tutorial). Erik Meijer: Haskell Server Pages: Functional Programming and the Battle for the Middle Tier Demonstrates that embedding a programming language into HTML breaks abstraction. The system allows embedding HTML syntax directly into a Haskell program, using a preprocessor. Chris Okasaki: An Overview of Edison Chris presented his library of data structures. A usable version exists in the hslib. Slow further development, Chris asks for contributions. The library uses multiparameter classes although it claims to adhere to Haskell 98. Chris points out some Haskell features that influenced/hampered the design: qualified infix operators are ugly; missing exceptions for non-IO stuff; checkable preconditions that a function is monotonic would be useful; default implementations of classes useless; form of contexts too restrictive. Doaitse Swierstra: Combinator Parsers: From Toys to Tools A new version of his parser combinators. He started nicely by using an infinite trie to represent all words of the parsed language. But he did not develop his combinators systematically as John Hughes. The paper has few references, no references to other efficient parser combinators, e.g. Daan Leiden's ones that are in hslibs. Peter Ljunglof: Typed Logical Variables in Haskell I missed the point of having Prolog combinators in Haskell. It does not give you a functional-logic language such as Curry. John Peterson: Functional Reactive Programming (10 minute talk) Yale plans to put some research effort into the devoplment of embedded domain specific languages for functional reactive programming, e.g. programming robots for winning the robocup next year. Nothing definite. Andy Gill: Debugging Haskell by Observing Intermediate Data Structures People showed considerable interest in debugging. However, interested people were asked to meet Malcolm, but only Meurig Sage and Ralf Hinze showed up. Adam Bakewell: A Space-Semantics for Core Haskell The slides with the comics caused lots of applause. People asked Adam to put them on the web. People asked several questions about what it exactly means for two implementations to have the same space behaviour. Malcolm Wallace: hi (10 minute talk) Several people showed interest in using hi or implementing it for other languages. The good performance of ghc was a surprise. John Peterson: haskell.org (10 minute talk) John promised web forms so that everybody can update information about libraries, tools etc to appear very soon on haskell.org. He already told me about that more than a year ago, to happen quite soon. John asked for participation in extending haskell.org and gives the root password to anybody who asks for it. Jerzy Karczmarczuk: "Differentiation of functions and Lazyness" (10 minute talk) Jerzy presented a very sophisticated algorithm for differentiating functions that requires lazyness. I wonder if anybody understood it. Ralf Hinze: Derivable Type Classes Ralf and Simon integrated Ralf's work on generic programming that he presented on last year's Haskell workshop better into Haskell. The default methods are used to generically define instances. However, some extensions of the language are necessary and a few decisions seem arbitrary. Jonas Hormerin, Bjorn Lisper: Data Field Haskell An extension of Haskell to support data fields in Haskell, a kind of array with arbitrary index domain (e.g. for sparse matrices). Implementation is modification of nhc13. Simon Peyton Jones: Pattern Guards and Transformational Patterns Pattern guards (that is <- and let in patterns, as in list comprehensions and do notation) as already proposed for some time by Simon on a web page. Discussion of some further related extensions. Discussion: The Future of Haskell John Launchbury presented slides with many proposed extensions for Haskell. However, in the discussion many different opinions about the desirable future of Haskell were raised. The large number of extension proposals probably stopped those who were in favour of some extensions and Haskell 2 to appear soon. Many doubted that it is the lack of features that hinder Haskell in becoming more widely accepted (and the discussion partly went into the popular debate about how to make functional languages more popular). The concern was raised that many extension proposals were still vague and limited practical experience regarding their usefulness had been gained. Implementors should communicate to keep common extensions consistent. People seriously interested in an extension should get together, write a precise document about the extension (publish it on haskell.org) and get at least one implementor to implement it. The FFI is probably the best example for this. Dropping a feature of Haskell was not seriously discussed. TRACING At the PLI 2000 meetings we had various discussions with individuals about tracing, and we also convened an ad hoc discussion meeting for people interested in tracing. This memo is a (fragmentary) record of these discussions. DISCUSSION MEETING Those present at the meeting in addition to ourselves were: Carl Seger (Intel) Andy Gill (Galois) Richard Watson (Australia, visiting OGI) Meurig Sage (Glasgow) Ralf Hinze (Bonn) After introductions we began with illustrative demonstrations of three tracing systems (Carl's debugger for Forte, Andy's HOOD, our Hat 1.0). There were also `paper simulations' of algorithmic debugging in Freja, and sequential tracing as implemented by Richard. The simple example program we used for these demonstrations was something like: main = print (f 3) f x = dec x + inc x - 1 where dec x = x - 1 inc x = x + 1 Although all the systems could provide a more or less sensible account of such a simple program, we agreed that *none* of them had yet matured to the stage of a robust and dependable tool ready for use by the developers of serious applications. For applicability in practice, at least three areas need work: (1) handling long-running programs without consuming infeasible amounts of time and/or memory; (2) portably supporting the full repertoire of Haskell 98, not forgetting monadic programs; (3) specifying appropriate strategies for debugging that can be implemented using available tools. However, all the systems we considered showed promise, and the call for `a Haskell debugger' was louder than ever. Those of us working on tracing/debugging tools should be aiming to deliver something in time for the Haskell workshop 2001. It was useful to try several different approaches, but we should also collaborate. There have been many past attempts to develop a functional tracer/debugger but most have ended up as bit-rotted tar files before they were ever widely used. Now is the time to stop the rot! To understand the strengths and weaknesses of a tracer it would be useful to have something like the benchmark suites used by compiler writers to measure their success. In the context of tracing what seems to be needed is a collection of ten or twenty benchmark programs, of various sizes and styles, and for each of these: (1) a clear source of the working program; (2) a set of specific questions about how the program works that are not easily answered just by looking at the source, but which one would hope could be answered by using a tracer; (3) a broken version of the program that still compiles despite the deliberate introduction of bugs; (4) a set of questions about this program (though one could make do with the implicit question `Where are the bugs?', to be answered without direct comparison of the broken and unbroken sources). We should aim to include a preliminary set of such tracing benchmarks in the next release of nhc+hat. To avoid (the charge of) bias the origins of the benchmark programs should be diverse. Finally, besides the obvious practical motivation of a Haskell Debugger, there are interesting questions about traces from the academic point of view. These include: (1) the relative power or information content of different types of trace; (For example, can EDTs be extracted from redex trails?) (2) the design space for trace representations, and for query or programming languages over traces as data structures; (For example, what could a programmer's interface to archived redex trails be?) (3) how to evaluate the effect of tracers in terms of an explicit model of cognitive processes in the programmer, or repeatable laboratory experiments examining the success of trace users. INDIVIDUAL DISCUSSIONS As well as leaving piles of ART/Hat Bulletin 1 on the tables of handouts for conference people, we handed some out individually and tried to encourage potential users. In my opinion, we don't need or want a *lot* of users: if we had, say, 100 active users we might spend too much time trying to respond to their requests. However, we do need *some* users: (1) to find and report problems; (2) to make suggestions about what would improve tracing in practice; (3) to provide application-driven pull; (4) to become enthusiasts (hopefully!) who will promote wider use and justify further development of tracers like Hat. The immediate requests to interested parties are: (1) make contact: let us know they are there and interested; (2) try the tracer: give us some kind of feedback; (3) contribute to the Tracing Benchmarks.