October 2004 - Haskell

Program maintenance tools
by Gavin Lowe 12 Oct '04

12 Oct '04

Hello I'm looking for some tools to help maintain a largish Haskell program. Some of the things I'd like tool support for are: - detection of dead code; - detection of unnecessary arguments for functions; - detection of unnecesary imports of modules; - a graphical representation of dependencies between modules. Any pointers would be much appreciated. Gavin -- Gavin Lowe Oxford University Computing Laboratory, Parks Road, Oxford, OX1 3QD. Phone: +44 1865 273841. Fax: +44 1865 273839. E-mail: gavin.lowe(a)comlab.ox.ac.uk The secret of all discoverers is that they regard nothing as impossible

4 3

Re: elementary tracing for Haskell
by Thomas Davie 12 Oct '04

12 Oct '04

Hi, I'm glad that there's interest for a tool like hat-anim. I should warn you however that the current version is far from perfect - it has some problems with displaying infinite lists and with some lambda expressions and worst of all has a pretty nasty memory leek problem (there's what I get for writing it in C). I am currently re-writing it in Haskell, and hopefully will produce a more reliable tool. I'll tell you when the tool is working. Thanks Tom Davie On 12 Oct 2004, at 14:34, Olaf Chitil wrote: > > > From: Colin Runciman <colin(a)cs.york.ac.uk> > Date: 11 October 2004 10:38:21 BST > To: Philip Wadler <wadler(a)inf.ed.ac.uk> > Cc: John Hughes <rjmh(a)cs.chalmers.se>, haskell(a)haskell.org, Simon > Thompson <S.J.Thompson(a)kent.ac.uk>, Susan Eisenbach > <sue(a)doc.ic.ac.uk> > Subject: [Haskell] Re: elementary tracing for Haskell > > > Phil, > >> Are there any tools for beginning programmers that give traces of >> Haskell programs? I want something like the following. Given the >> defintion >> >> sum [] = 0 >> sum (x:xs) = x + sum xs >> >> typing >> >> sum [1,2,3] >> >> should yield this trace >> >> sum [1,2,3] >> 1 + sum [2,3] >> 1 + 2 + sum [3] >> 1 + 2 + 3 + sum [] >> 1 + 2 + 3 + 0 >> 1 + 2 + 3 >> 1 + 5 >> 6 >> >> I know there are advanced tools like Hat, but (unless I'm missing >> something) they don't yield anything as naive as the above, and it's >> naive users I'm trying to help here. -- P > > There is a Hat tool called hat-anim that can do this kind of thing. > It was developed by Tom Davie as a student project. It is not part of > the current "official release" of Hat but is included in the CVS > version. Tom is now a PhD student at Canterbury (tatd2(a)kent.ac.uk) > supervised by Olaf Chitil (O.Chitil(a)kent.ac.uk) > > Regards > Colin R > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > >

1 0

looking for reference to wadler's (?) law of language design
by Johannes Waldmann 12 Oct '04

12 Oct '04

this is slightly off topic - I am preparing for a lecture on domain specific languages and I try to track down the source and original version of (what I recall as) Wadler's "law" of language design, "the energy spent in designing a programming language goes into, in increasing order of effort: semantics, syntax, syntax of comments". -- -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- ------ http://www.imn.htwk-leipzig.de/~waldmann/ ---------

2 1

-allow-extension-for-bottom
by Serge D. Mechveliani 12 Oct '04

12 Oct '04

Dear Haskell implementors, Consider the compilation flag -allow-extension-for-bottom which changes the language meaning so that allows to ignore the bottom value. For example, the programs (1) (\ x -> (if p x then foo (g x) else foo (h x)) ) and (2) (\ x -> foo ((if p x then g x else h x)) ) become equivalent, and many program transformations become possible. I suspect that after compiling and running of a program under -allow-extension-for-bottom the user will discover many helpful information about the original program. For example, under -allow-extension-for-bottom it may run 1000 times faster, and then, the user finds out what to change to have a 1000 times speed-up for the original program for the standard Haskell. Thus, in my particular practical example, it is evident to me that it is better to specify (2). But many similar effects are hard to find out without compiling under -allow-extension-for-bottom. Maybe, the compiler could issue the warnings like, say, "Consider factoring `if' in ... This may improve ... " ? Copy, please, the answer to mechvel(a)botik.ru, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

Call for Contributions -- HC&A Report (November 2004 edition)
by Andres Loeh 11 Oct '04

11 Oct '04

Dear Haskellers, another six months have passed, and another change of editor has occurred. Half a year usually also is plenty of time for several productive changes and news to occur within the Haskell community, and therefore it is time for you to start writing: please contribute to the forthcoming seventh edition of the ================================================================ Haskell Communities & Activities Report http://www.haskell.org/communities/ Submission deadline: 29 October 2004 (please send your contributions to hcar(a)haskell.org, in plain ASCII or LaTeX format) ================================================================ The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming 6 months. If you have only recently been exposed to Haskell, it might be a good idea to browse the May 2004 edition -- you will find interesting topics described as well as several starting points and links that may provide answers to many questions. The plan is to collect contributions until roughly the end of October, then start to compile them into a coherent report which will appear during November. As always, this is a great opportunity to update your webpages, make new releases, announce of even start new projects, or to point at some developments you want every Haskeller to see! As the purpose of the report is to collect recent or current activities, we encourage you to update all existing summaries and reports. We will drop any topics that have not had any activity for the past year, i.e., since November 2003, but we would very much prefer you to present an updated description of the topic. Of course, new entries are more than welcome. Reports should generally be kept brief and informative, ranging from a few sentences to a few hundred words, to keep the whole report reasonably sized. Looking forward to your contributions, Andres (current editor) ----------------------------------- topics New suggestions for current hot topics, activities, projects, etc. are welcome - especially with names and addresses of potential contacts, but here is a non-exclusive list of likely topics (see also http://www.haskell.org/communities/topics.html ): General Haskell developments; Haskell implementations; Haskell extensions; Standardization and documentation; Haskell tutorials, howtos and wikis; Organisation of Haskell tool and library development; Haskell-related projects and publications; new research, fancy tools, long-awaited libraries, cool applications; Feedback from specialist mailing lists to the Haskell community as a whole; Haskell announcements; all (recent) things Haskell Announcements: if you've announced anything new on the Haskell list over the last six months, you'll want to make sure that is reflected in this edition! Project pings: if you're maintaining a Haskell tool or library or somesuch, you'll want to let everyone know that it is still alive and actively maintained, even if there have been no new additions, but all the more if there have been new developments. Tutorials: if you've fought with some previously undocumented corner of Haskell, and have been kind enough to write down how you did manage to build that graphical user interface, or if you've written a tutorial about some useful programming techniques, this is your opportunity to spread the word (short, topic-specific, and hands-on tutorials that only show how to achieve a certain practical task would do a lot to make things easier for new Haskellers - please write some!) Applications: if you've been working quietly, using Haskell for some interesting project or application (commercial or otherwise), you might want to let others know about what you're using Haskell for, and about your experiences using the existing tools and libraries; are you using Haskell on your job? An interesting thread about using Haskell and more generally functional programming for non-Haskell things seems to recur with reasonable frequency - why not write a sentence or two about your use of Haskell for our report? Feedback: if you're on one of the many specialist Haskell mailing lists, you'll want to report on whatever progress has been made there (GUI API discussions, library organisation, etc.) If you're unsure whether a contact for your area of work has come forward yet, have a look at the report's potential topics page, or get in touch with me. I have contacted last time's contributors, hoping they will volunteer to provide updates of their reports, and will update the contacts on the topics page fairly regularly. But where you don't yet see contacts listed for your own subject of interest, you are very welcome to volunteer, or to remind your local community/project team/mailing list/research group/etc. that they really ought to get their act together and let the Haskell community as a whole know about what they've been doing! :-) -------------------------- what should I write? That depends on your topic, but as a general rule, it shouldn't take you long. A simple sentence or two about your use of Haskell could go into the "Individual Haskellers and their projects" section. If you're a company, or if you're working on a project using Haskell as the implementation language, a paragraph on that could go into the "Commercial Applications" and "Non-Commercial Applications" sections. A typical summary report about a tool/library/project/application/... would be between 1 and 3 paragraphs of ASCII text (what's it about? major topics and results since the last report? current hot topics? major goals for the next six months?) plus pointers to material for further reading (typically to a home page, or to mailing list archives, specifications and drafts, implementations, meetings, minutes, ...). For those who prefer templates to fill in, the report is edited in LaTeX, and an entry template might look something like this: \subsubsection{<MYSTUFF>} \report{<MY NAME}\\ <WHAT IS IT?> <WHAT IS ITS STATUS? / WHAT HAS HAPPENED SINCE LAST TIME?> <CAN OTHERS GET IT?> <WHAT ARE THE IMMEDIATE PLANS?> <FURTHER READING> \url{<PROJECT URL>} Browsing through previous editions should give you a good idea of the variety of possibilities, ranging from very brief to extensive. -- Haskell Communities and Activities Report Please send submissions for the 11/2004 edition before 29 October 2004 to <hcar(a)haskell.org>.

1 0

Re: factoring `if'
by Serge D. Mechveliani 11 Oct '04

11 Oct '04

Thanks for the help! People note that in my example of > > (1) (\ x -> (if p x then foo (g x) else foo (h x)) ...) > > > > (2) (\ x -> foo ((if p x then g x else h x)) ) p x may be _|_, and this makes (1) not equivalent to (2). ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

factoring `if'
by Serge D. Mechveliani 11 Oct '04

11 Oct '04

Dear Haskell implementors, How do you think, is the program (1) equivalent to (2) in the meaning of Haskell-98 ? (1) (\ x -> (if p x then foo (g x) else foo (h x)) where p ... g ... h ... foo ... ) (2) (\ x -> foo ((if p x then g x else h x) where p ... g ... h ... foo ... ) ) If it is equivalent, then does it make sense for a compiler to convert (1) to (2): to separate a common `factor' of the if-branches ? The reason for this may be, for example, that the result printing of (f x) is more `lazy' in (2) than in (1): the part of foo may print immediately and (g x) or (h x) may print long after. This is a difference in behavior, it does not effect the computation meaning. I have a large program which is easily written in the style of (1), (and in many places it sets `case' instead of `if'). Annoyingly, it prints out in a not a lazy manner. It can be rewritten in the form of (2), but with effort, and it will look less plain. So, maybe, this is a business of a compiler? Copy, please, the possible answer to mechvel(a)botik.ru ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

elementary tracing for Haskell
by Philip Wadler 11 Oct '04

11 Oct '04

Are there any tools for beginning programmers that give traces of Haskell programs? I want something like the following. Given the defintion sum [] = 0 sum (x:xs) = x + sum xs typing sum [1,2,3] should yield this trace sum [1,2,3] 1 + sum [2,3] 1 + 2 + sum [3] 1 + 2 + 3 + sum [] 1 + 2 + 3 + 0 1 + 2 + 3 1 + 5 6 I know there are advanced tools like Hat, but (unless I'm missing something) they don't yield anything as naive as the above, and it's naive users I'm trying to help here. -- P PS. Google search on "Haskell trace" yields lots on Hat, plus the following. The Mystery of Brigadier General Harry L. Haskell ... we have developed a short biography of General Haskell and been able to trace the locations where he lived, and, possibly, how the medal came into my family. ... family.phelpsinc.com/branches/haskell/ - 28k - Cached - Similar pages Philip Wadler, Professor of Theoretical Computer Science School of Informatics, University of Edinburgh JCMB, Mayfield Road, Edinburgh EH9 3JZ SCOTLAND +44 131 650 5174 http://homepages.inf.ed.ac.uk/wadler/

2 1

GHC / Hugs Disagree on Constraints
by oleg＠pobox.com 11 Oct '04

11 Oct '04

> instance (Ord a, Bits a, Bounded a, Integral a, LargeWord a, > Bits b, Bounded b, Integral b, LargeWord b) => > Bounded (LargeKey a b) where > minBound = 0 > maxBound = > fromIntegral $ > (1 + fromIntegral (maxBound::b))* > (1 + fromIntegral (maxBound::a)) - 1 > > Hugs rejects it with +N -98 with One fix is to bring type variables into the local scope, for example, > instance (Ord a, Bits a, Bounded a, Integral a, LargeWord a, > Bits b, Bounded b, Integral b, LargeWord b) => > Bounded (LargeKey a b) where > minBound = 0 > maxBound :: (LargeKey a b) = > fromIntegral $ > (1 + fromIntegral (maxBound::b))* > (1 + fromIntegral (maxBound::a)) - 1 You still need -98 flag for Hugs. Another solution is totally Haskell98: introduce two functions > aoflk:: (LargeKey a b) -> a; aoflk = undefined > boflk:: (LargeKey a b) -> b; boflk = undefined then maxBound can be implemented as > maxBound = result where > result = > fromIntegral $ > (1 + fromIntegral (maxBound `asTypeOf` (boflk result)))* > (1 + fromIntegral (maxBound `asTypeOf` (aoflk result))) - 1 The apparent recursion in the above definition is superficial. The definition isn't actually recursive. We merely need the type of the 'result' rather than its value.

3 4

CFP: TFP04 Symp on Trends in Functional Programming
by Hans-Wolfgang Loidl 09 Oct '04

09 Oct '04

[ The registration page for TFP04 is now open: registration deadline is Nov 1; Deadline for paper submissions is Nov 15th. Apologies for repeated copies of this message -- HWL ] CALL FOR PAPERS TFP 2004 Fifth Symposium on Trends in Functional Programming November 25-26th 2004, Ludwig-Maximilians University, Munich, Germany http://www.tcs.ifi.lmu.de/~hwloidl/TFP04 The Symposium on Trends in Functional Programming is an international forum for researchers with interests in all aspects of functional programming languages. It succeeds TFP03 in Edinburgh and continues the Scottish Functional Programming Workshop series from 1999-2002. Papers on all aspects of functional programming are welcomed, be they theoretical, implementation-oriented, or experience papers. The venue for this year's symposium will be Ludwig-Maximilians University in central Munich. WORKSHOP TOPICS Papers on any aspect of functional programming are welcomed. Papers on the following subject areas are particularly welcome: * design and implementation of functional or declarative languages; * rich type systems, including type systems for expressing side-effects, resource bounds, or other safety properties; * linear type systems, soft type systems, typeful programming; * formal aspects of functional programming, semantics, reasoning, verification; * inductive or co-inductive techniques, proof nets; * mobile-code functional programming languages; * parallel programming with functional languages, cost models for functional programs; * functional aspects of imperative programming, functional bytecode; * interoperability with imperative programming languages, calling imperative from functional or vice versa; * type inference algorithms, type error repair, deep types; * strongly-typed imperative languages with inference; * optimisation techniques, implementation techniques, and performance measurements; * experience papers: applications of functional programming or functional programming in education. PROCEEDINGS As with the previous instances of TFP and SFP, we intend to publish a high-quality subset of contributions in the Intellect Trends in Functional Programming series. All speakers attending the workshop are invited to submit a paper for the draft proceedings. Revised papers will be refereed after the symposium according to normal conference standards for publication by Intellect. This implies (among other things) that: * the paper should be written in English * the paper is well written * the topic of the paper should be stated clearly * the approach to solve the problem should be outlined clearly * a detailed discussion of the solution has to be given * the solution is compared with relevant related work * there is an abstract, introduction and conclusion. * the conclusion should summarise the problem, the solution, and how this solves the problem. * papers must not exceed 16 pages. * the paper should conform to the TFP format <http://www.tcs.ifi.lmu.de/~hwloidl/TFP04/cameraready.zip> * the paper should be submitted as a PostScript or a PDF file using the paper submission page <http://lionel.tcs.informatik.uni-muenchen.de/TFP04/submit.html> in case of problems with the on-line submission process, send the paper by email to the programme chair, Hans-Wolfgang Loidl <hwloidl(a)informatik.uni-muenchen.de> DATES Nov 1st 2004: Registration deadline Nov 15th 2004: Submission for draft proceedings Nov 25-26th 2004: Symposium at Ludwig-Maximilians University, Munich Dec 20th 2004: Submission for referees process Jan 31st 2005: Notification of acceptance/rejection PREVIOUS WORKSHOPS The previous instance of TFP was held in Edinburgh 2003 and continues the Scottish Functional Programming Workshop series with previous meetings at Stirling (2001), St. Andrews (2000), and Stirling (1999). The TFP series <http://www.tifp.org/> strives to combine an active workshop environment for presenting latest research, with a formal post-symposium refereeing process and the publication of a high-profile proceedings (see <http://www.intellectbooks.com/authors/hammond/trends3.htm>). For a review of past TFP proceedings, see the July 2003 issue of the JFP 13(4):823-824 at <http://titles.cambridge.org/journals/JFP/>. Sponsorship funding available to us will be used to reduce registration rates for PhD students, who present proof of affiliation in advance of the symposium. PROGRAM COMMITTEE * Stephen Gilmore, University of Edinburgh * Gaetan Hains, Universite d'Orleans * Kevin Hammond, University of St Andrews * John Hughes, Chalmers University * Hans-Wolfgang Loidl, Ludwig-Maximilians-University Munich (Chair) * Rita Loogen, Philipps-University Marburg * Greg Michaelson, Heriot-Watt University * John O'Donnell, University of Glasgow * Ricardo Pena, Universidad Complutense de Madrid * Phil Trinder, Heriot-Watt University * Marko van Eekelen, University of Nijmegen * Phil Wadler, University of Edinburgh SPONSORS TFP is supported this year by the APPSEM II Thematic Network and the Mobile Resource Guarantees project, funded by the IST programme of the European Union.

1 0