September 2002 - Haskell

RE: Haskell 98
by Simon Peyton-Jones 19 Sep '02

19 Sep '02

| > contributions. So the book currently shows me as editor, while the | > preface attempts to give credit where credit is due. Please help me to | > improve it. | > | You don't specify very clearly when someone deserves to be on the | contribution list. | | I reported some errors in the report which gave rise to some changes. If | that counts as a contribution I think my name should be on the list. You are right; I should have been clearer. Yes, you should be on the list! My intention was to add someone to the acknowledgements list as soon as they contributed *anything*. Please tell me if I have missed you off. Josef, I'll add you right now Simon

1 0

FOOL'03: Final Call for Papers
by ghelli 19 Sep '02

19 Sep '02

Deadline is very near; please notice alternate web site. The Tenth International Workshop on Foundations of Object-Oriented Languages FOOL 10 Sponsored by ACM SIGPLAN January 18, 2003 New Orleans, Louisiana Following POPL '03 Deadlines Submissions: September 30, 2002 Notifications: November 15, 2002 Final versions: December 12, 2002 Conference: January 18, 2003, following POPL Submission: an extended abstract which should not exceed 5000 words (approximately 10 pages) More details in: http://www.cis.upenn.edu/~bcpierce/FOOL/FOOL10.html http://tql.di.unipi.it/fool10/fool10.htm mailto:fool10@di.unipi.it ------------------------------------------------------------------------ ---- Prof. Giorgio Ghelli, PhD Universita' di Pisa, Dipartimento di Informatica, Corso Italia 40, I-56125, Pisa, ITALY mailto:ghelli@di.unipi.it http://www.di.unipi.it/~ghelli Fax: +39 050 2212 726 ------------------------------------------------------------------------ ----

1 0

Call for Papers - TACAS 2003
by John Hatcliff 18 Sep '02

18 Sep '02

[%%%% Apologies for multiple copies received %%%%] CALL FOR PAPERS Ninth International Conference on TOOLS AND ALGORITHMS FOR THE CONSTRUCTION AND ANALYSIS OF SYSTEMS (TACAS 2003) 7-11 April 2003 Warsaw, Poland URL: http://www.mimuw.edu.pl/etaps03 A member conference of the European Joint Conferences on Theory and Practice of Software (ETAPS 2003) CONFERENCE DESCRIPTION TACAS is a forum for researchers, developers and users interested in rigorously based tools for the construction and analysis of systems. The conference serves to bridge the gaps between different communities --- including but not limited to those devoted to formal methods, software and hardware verification, static analysis, programming languages, software engineering, real-time systems, and communications protocols --- that have traditionally had little interaction but share common interests in, and techniques for, tool development. In particular, by providing a venue for the discussion of common problems, heuristics, algorithms, data structures and methodologies, TACAS aims to support researchers in their quest to improve the utility, reliability, flexibility and efficiency of tools for building systems. Tool descriptions and case studies with a conceptual message and theoretical papers with a clear link to tool construction are all encouraged. The specific topics covered by the conference include, but are not limited to, the following. Specification and verification techniques Theorem-proving and model-checking System construction and transformation techniques Static and run-time analysis Compositional and refinement-based methodologies Testing and test-case generation Analytical techniques for real-time, hybrid and safety-critical systems Tool environments and tool architectures Applications and case studies As TACAS addresses a heterogeneous audience, potential authors are strongly encouraged to write about their ideas in general and jargon-independent, rather than application- and domain-specific, terms. Authors reporting on tools or case studies are strongly encouraged to indicate how their experimental results can be reproduced and confirmed independently. TACAS is a member of the European Joint Conference on Theory and Practice of Software (ETAPS), which is the primary European forum for academic and industrial researchers working on topics related to Software Science. After ETAPS 98 in Lisbon, ETAPS 99 in Amsterdam, ETAPS 2000 in Berlin, ETAPS 2001 in Genova, and ETAPS 2002 in Grenoble, ETAPS 2003 is the sixth joint conference in this series. SUBMISSION GUIDELINES As with other ETAPS conferences, TACAS accepts two types of contributions: - Research papers (up to 16 pages) cover one or more of the topics above, including tool development and case studies from a perspective of scientific research. Research papers are evaluated by the TACAS Program Committee under the direction of the Conference Co-chairs. See http:///www.cis.ksu.edu/tacas03 for details. - Tool demonstration papers (up to 4 pages) present tools based on aforementioned technologies (e.g., theorem-proving, model-checking, static analysis, or other formal methods) or fall into the above application areas (e.g., system construction and transformation, testing, analysis of real-time and hybrid systems, etc.). Tool demonstration papers are evaluated by the TACAS Tool Chair with the help of the Program Committee. See http://www.inrialpes.fr/vasy/tacas03/tool.html for details. Both types of contributions will appear in the proceedings and be allocated thirty-minute slots during the conference. In brief, submitted papers must - be in English - present original research which is unpublished and not submitted elsewhere - use the Springer-Verlag LNCS style (see http://www.springer.de/comp/lncs/Authors.html) - be submitted electronically in Postscript/PDF format Submissions deviating from these instructions may be rejected without review. Any question regarding this policy should be directed to the Conference Co-chairs prior to submission. IMPORTANT DATES TACAS is a member conference of ETAPS. ETAPS 2003 conferences and other satellite events will be held April 5-13, 2003. As a part of ETAPS, TACAS adheres to ETAPS submission and notification deadlines. October 18, 2002 Submission deadline December 13, 2002 Notification of authors January 17, 2003 Final versions due April 7-11, 2003 Conference dates INVITED SPEAKER Peter Lee School of Computer Science Carnegie Mellon University, USA PROGRAM COMMITTEE Rajeev Alur University of Pennsylvania (USA) Albert Benveniste IRISA Rennes (France) Ahmed Bouajjani Liafa, Paris 7 (France) Rance Cleaveland (TACAS SC) SUNY at Stony Brook (USA) Werner Damm Univ. Oldenburg (Germany) Luca de Alfaro University of California, Santa Cruz (USA) Alessandro Fantechi Univ. of Florence and IEI- CNR Pisa (Italy) Alain Finkel LSV Cachan (France) Hubert Garavel (co-chair) Inria Rhône-Alpes (France) Patrice Godefroid Bell Laboratories, Lucent Technologies (USA) Susanne Graf Verimag Grenoble (France) Jan-Friso Groote Techn. Univ Eindhoven (The Netherlands) Orna Grumberg Technion Haifa (Israel) John Hatcliff (co-chair) Kansas State University (USA) Kurt Jensen (tool chair) University of Aarhus (Denmark) Bengt Jonsson Uppsala University (Sweden) Joost-Pieter Katoen Universiteit Twente (The Netherlands) Kim Larsen Aalborg U. (Denmark) Doron Peled University of Texas (USA) Sriram K. Rajamani Microsoft Research (USA) John Rushby SRI (USA) Steve Schneider Royal Holloway, University of London (UK) Gregor Snelting Univ. Passau (Germany) Bernhard Steffen Universität Dortmund (Germany) Willem Visser RIACS, NASA Ames Research Center (USA) PROGRAM COMMITTEE CHAIRS: Hubert Garavel John Hatcliff INRIA Rhone-Alpes, France Kansas State University http://www.inrialpes.fr/vasy http://www.cis.ksu.edu/~hatcliff TOOL CHAIR: Kurt Jensen (tool chair) University of Aarhus (Denmark)

1 0

ANNOUNCE: new FGL version released
by Martin Erwig 18 Sep '02

18 Sep '02

FGL - A Functional Graph Library, Version: September 2002 ========================================================= I am happy to announce a new release of the Functional Graph Library for Haskell, a collection of graph algorithms and tools. New in this release: * Introduction of graph classes * Monadic graphs and graph computation monad * Graph implementation based on balanced (AVL) trees * Fast graph implementation based on IO arrays * New algorithms: - Maximum flow - Articulation points - Biconnected components - Dominators - Transitive closure * minor changes in utility functions Download: http://cs.oregonstate.edu/~erwig/fgl/haskell/ Please email comments, bugs, etc. to erwig(a)cs.orst.edu -- Martin

1 0

RE: Haskell 98: Behaviour of hClose
by Simon Peyton-Jones 18 Sep '02

18 Sep '02

| No yelling, but some random points for consideration: | | 1. It might be worth being more explicit, i.e. stating whether this is | because the runtime explicitly enables echoing, or because it's | assumed that echoing will already be enabled. Well, at Haskell user doesn't care. It's precisely because we want to specify the behaviour of Haskell programs, regardless of the underlying OS, that it's worth trying to nail down these things. If the Haskell RTS has to nudge the OS into echoing, that's what it should do. This only applies the default settings. (You can change echoing settings via the IO.hSetEcho etc.) | 2. Is there actually anything special about the treatment of stdin, or | does this apply to any input stream which is associated with a | terminal? I'm proposing just stdin. My motivation is to make simple stupid programs work right. If people open other terminal devices they are much more likely to know what they are doing. It would be reasonable to pin down what happens in that case, but I'm desperately afraid of opening Pandora's box when I have to deliver the final bits to CUP in a couple of weeks. So, stdin only for now. | 3. In general, "magic" behaviour (e.g. clearing the ICANON flag when | disabling buffering) should at least be documented, otherwise it's | likely to confuse experienced programmers. Well I have never heard of the ICANON flag! I don't expect to put it in the Haskell report unless someone tells me it's absolutely unavoidable! Simon

5 4

"where" block local to a guard?
by Dr Mark H Phillips 18 Sep '02

18 Sep '02

Hi, Suppose you have some function functn :: Int -> Int functn i | i>5 = t * i | i>0 = t_ * i | otherwise = 1 where t = functn (i-2) t_ = functn (i-1) Notice that t and t_ are really local to a guard, rather than to the whole guard section. Why then, can't you write: functn :: Int -> Int functn i | i>5 = t * i where t = functn (i-2) | i>0 = t * i where t = functn (i-1) | otherwise = 1 In particular, the above would mean you wouldn't need two names t and t_, you could just use t for both! Am I doing something wrongly, or is there a good reason why where isn't allowed to be used in this way? Thanks, Mark. -- Dr Mark H Phillips Research Analyst (Mathematician) AUSTRICS - smarter scheduling solutions - www.austrics.com Level 2, 50 Pirie Street, Adelaide SA 5000, Australia Phone +61 8 8226 9850 Fax +61 8 8231 4821 Email mark(a)austrics.com.au

5 7

RE: Haskell 98: Behaviour of hClose
by Simon Peyton-Jones 18 Sep '02

18 Sep '02

What I intended was a simple interactive Haskell program should behave the same on any OS/environment What you and Ross seem to be saying is no, the behaviour of the program can, and should, depend on the OS/environment If that's the consensus I'll happily leave echoing behaviour unspecified. Remember, that means that a conforming implementation can do whatever it pleases, and hence it's impossible to write a portable interactive Haskell program. Is that you what you intend? It's really a pain that this has come up so late in the day. Simon | -----Original Message----- | From: Ferenc Wagner [mailto:wferi@bolyai1.elte.hu] | Sent: 18 September 2002 11:50 | To: haskell(a)haskell.org | Subject: Re: Haskell 98: Behaviour of hClose | | Ross Paterson <ross(a)soi.city.ac.uk> writes: | | > So I favour deletion of the offending sentence, leaving | > this as an environment-dependency. | | I second that. I came to Haskell after many other | programming languages, and was VERY surprised by echo | behaviour. I vote for consistency with long-standing | standards (C library, every other language) and versatility | (echo and buffering determined by environment -- it should | be configured to also run non-Haskell programs, after all). | | Feri. | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

5 4

RE: Haskell 98: Behaviour of hClose
by Simon Peyton-Jones 18 Sep '02

18 Sep '02

Ahem how true. I have not idea why it was removed. But I can't put anything back in at this stage. Simon | -----Original Message----- | From: Malcolm Wallace [mailto:Malcolm.Wallace@cs.york.ac.uk] | Sent: 18 September 2002 10:04 | To: Simon Peyton-Jones | Cc: haskell(a)haskell.org | Subject: Re: Haskell 98: Behaviour of hClose | | "Simon Peyton-Jones" <simonpj(a)microsoft.com> writes: | | > (You can change echoing settings via the IO.hSetEcho etc.) | | Ahem, one of the deficiencies of Haskell'98 is that there is no function | IO.hSetEcho. There used to be one in Haskell 1.3 I think, so I guess there | was a good reason for removing it? | | Regards, | Malcolm

1 0

Q: Forcing repeated evaluation
by Jan Kybic 18 Sep '02

18 Sep '02

Hello, I have another question regarding the optimisation of Haskell code: I have a relatively inexpensive function generating a long list, imagine something like (I simplified a lot): l = [ i*i*i | i <- [0..n] ] -- for very large n This long list is consumed several times in the program: x1 = f1 l x2 = f2 x1 l x3 = f3 x2 l I found that the list l is calculated just once and that the computational time is dominated by the allocations and garbage collection. I want to try to force l to be generated on-the-fly every time it is needed, to see if it improves performance. What is a good way to do it? Would something like unsafePerformIO $ return l do the job? Isn'it there any flag for the compiler (ghc) to suggest this optimisation? Thank you for your feedback. Jan -- ------------------------------------------------------------------------- Jan Kybic <kybic(a)ieee.org> Odyssee, INRIA, Sophia-Antipolis, France or <Jan.Kybic(a)sophia.inria.fr>,tel. work +33 492 38 7589, fax 7845 http://www-sop.inria.fr/odyssee/team/Jan.Kybic/index.en.html

5 5

RE: Haskell 98: Behaviour of hClose
by Simon Peyton-Jones 17 Sep '02

17 Sep '02

Sigbjorn writes: | Re: your request to have a final look through the report | for any wibbles that might remain -- Section 11.3.2 of the | lib report isn't clear on what the expected behaviour of | (hClose h >> hClose h) ought to be, i.e., will the second | hClose fail or not? | | Both GHC and Hugs will now not raise an error when | an already closed file is closed again. I'm inclined to agree. Making hClose on a closed handle into a no-op is sometimes convenient for the programmer, and not hard for the implementation to support. So I propose to specify that in H98. Meanwhile I only had one reply to this proposed clarification to input on "stdin": If the standard input (stdin) is a terminal device, any input on stdin is normally echoed on that device The "normally" clause is a weasel way to say that if you fiddle with the device then odd things may happen. The point is that programs like do { s <- getLine ; putLine (reverse s) } should work portably. If we leave this sentence out, then such programs are not portable. But they are some of the first programs people write, so it's important. In short, I propose to adopt this change unless there's a lot of yelling soon. Simon

2 1