September 2001 - Haskell

FME 2002: Call for Papers
by mailinglist-admin＠fmeurope.org 10 Sep '01

10 Sep '01

** Apologies if you receive multiple copies... ** ** Also apologies if you have unsubscribed to this mailing list in the past, we had to reinstall the original list and were unable to recover the unsubscriptions. Please note that the list is ONLY used to announce the 18-monthly FME (Formal Methods Europe) symposia. ** FORMAL METHODS EUROPE FME 2002 "Formal Methods: Getting IT Right" International Symposium and Tutorials http://floc02.diku.dk/FME/ 20-24 July 2002 Call for Papers *************** FME 2002 is the eleventh in a series of symposia organised by Formal Methods Europe, an independent association whose aim is to stimulate the use of, and research on, formal methods for software development. These symposia have been notably successful in bringing together a community of users, researchers, and developers of precise mathematical methods for software development. In 2002 the symposium will be held in conjunction with the third Federated Logic Conference (FLoC'02) in Copenhagen, Denmark. The theme of FME 2002 is Formal Methods: Getting IT Right. The double meaning is intentional. On the one hand, the theme acknowledges the significant contribution formal methods can make to Information Technology, by enabling computer systems to be described precisely and reasoned about with rigour. On the other hand, it recognises that current formal methods are not perfect, and further research and practice are required to improve their foundations, applicability and effectiveness. FME seeks papers in all aspects of formal methods for computer systems, including the following: * theoretical foundations * practical use and case studies * specification and modelling techniques * software development and refinement * tool support and software engineering environments for formal methods * verification and validation * hidden formal methods, and making benefits available to non-experts * reusable domain theories * method integration * hardware verification In addition to presentations of submitted papers, the symposium will offer tutorials, workshops, invited speakers, and tool demonstrations. PAPERS Full papers should be submitted in Postscript or PDF format by e-mail to reach the Program Co-chairs by 15 January 2002. Papers will be refereed by the Program Committee and must be original research papers that have not been submitted elsewhere for publication. Accepted papers will be published in the symposium proceedings. Papers should not exceed twenty pages, although longer papers will be considered if their content justifies it. LNCS format should be used: see http://www.springer.de/comp/lncs/authors.html for details. Please include a short list of keywords on a separate line at the end of the abstract, beginning with the word "Keyword:" in boldface. OTHER SYMPOSIUM ACTIVITIES Tutorials and workshops will be held on 20-21 July 2002. Each tutorial will last one-half or one day. Proposals are welcome, and should be directed to the Program Co-chairs by 15 January 2002; more details will appear on the web-site above. Tool demonstrations will also take place during the symposium, with the opportunity for presentations to be made about each tool. Proposals for tool demonstrations should be made to the Tool Demonstration Coordinator, with whom provison of necessary computing facilities should be discussed. PEOPLE Organising Chair Dines Bjørner Informatics and Mathematical Modelling Building 322, Richard Petersens Plads Technical University of Denmark DK-2800 Lyngby, Denmark Tel: +45 4525 3720 Email: db(a)imm.dtu.dk Programme Co-chairs Lars-Henrik Eriksson, Industrilogik L4i AB Box 21024, SE-100 31 Stockholm, Sweden Tel: +46 1859 1690 Fax: +46 1847 17058 Email: lhe(a)L4i.se Peter Lindsay, Software Verification Research Centre The University of Queensland, Queensland 4072, Australia Tel: +61 7 3365 2005 Fax: +61 7 3365 1533 Email: Peter.Lindsay(a)svrc.uq.edu.au Programme Committee Bernhard Aichernig Graz University of Technology, Austria Juan Bicarregui SERC Rutherford Labs, UK Ernie Cohen Telcordia Technologies, USA Ben Di Vito NASA Langley Research Center, USA Cindy Eisner IBM Haifa Research Laboratory, Israel Lars-Henrik Eriksson (co-chair) Industrilogik, Sweden John Fitzgerald Transitive Technologies Ltd, UK Jim Grundy Intel Corporation, USA Yves Ledru LSR/IMAG, Domaine Universitaire, France Peter Lindsay (co-chair) University of Queensland, Australia Markus Montigel University of New Orleans, USA Richard Moore IFAD, Denmark Tobias Nipkow Technische Universität München, Germany Colin O'Halloran Qinetiq (ex-DERA), UK Jose Oliveira Universidade do Minho, Portugal Nico Plat West Consulting, The Netherlands Jeannette Wing Carnegie Mellon University, USA Jim Woodcock Oxford University, UK Joakim von Wright Åbo Akademi University, Finland Pamela Zave AT&T Laboratories, USA Tool Demonstration Coordinator Paul Mukherjee The Institute of Applied Computer Sciense (IFAD) Forskerparken 10, DK-5230 Odense M, Denmark Tel: +45 6315 7131 Fax: +45 6593 2999 Email: paul.mukherjee(a)ifad.dk IMPORTANT DATES Submission of papers, tutorial proposals and workshop proposals: 15 January 2002 Notification of acceptance/rejection: 27 March 2002 Camera ready final version of papers due: 10 May 2002 _______________________________________________ Mailinglist mailing list Mailinglist(a)fmeurope.org http://www.fmeurope.org/mailman/listinfo/mailinglist

1 0

colored ASCII output?
by Johannes Waldmann 10 Sep '01

10 Sep '01

I am looking for a Haskell module that would allow me to easily send some escape sequences that generate coloured output (as ls --color does on a linux console or on rxvt). -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --

3 2

Call for papers
by José Luis Triviño 10 Sep '01

10 Sep '01

We apologize for possible multiple postings. In http://www.lcc.uma.es/icalp2002/c4p-sep01.pdf you can find a pdf version of this call for paper. +++++++++++++++++++++++++++++++++++++ Call for Papers ICALP 2002 29th International Colloquium on Automata, Languages and Programming July 8-13, 2002, Málaga, Spain Camera Ready: April 16, 2002 The 29th annual meeting of the European Association of Theoretical Computer Science will be held in Málaga, Spain, July 8-13, 2002 (at the E.T.S. Ingeniería Informática). As with the Journal Theoretical Computer Science (TCS), the scientific program of the Colloquium will be split into two parts: Track A of the meeting will correspond to Algorithms, Automata, Complexity and Games, while Track B to Logic, Semantics and Theory of Programming. SUBMISIONS: Authors are invited to submit extended abstract of their papers, presenting original contributions to the theory of computer science. Detailed instructions for paper submissions will be found on the conference webpage (http://www.lcc.uma.es/icalp2002) and in future calls for papers. Submissions should consist of: a cover page, with the author's full name, address, fax number, e-mail address, a 100-word abstract, keywords and to which track (A or B) the paper is being submitted and an extended abstract describing original research. At least one author of an accepted paper should be available to present it at the conference. Simultaneous submission to other conferences with published proceedings is not allowed. Further information (dates and instructions for submissions, workshops, registration, location and travel) will be provided in future announcements. ORGANIZING COMMITEE: Buenaventura Clares (University of Granada), Ricardo Conejo (University of Málaga), Inmaculada Fortes (University of Málaga), Llanos Mora (University of Málaga), Rafael Morales (co-Chair, University of Málaga), Marlon Nuñez (University of Málaga), José Luis Pérez de la Cruz (University of Málaga), Gonzalo Ramos (University of Málaga), Francisco Triguero (co-Chair, University of Málaga), José Luis Triviño (University of Málaga). IMPORTANT DATES: Workshops proposal: November 8, 2001 Submissions: January 14, 2002 Notification: March 20, 2002 CONFERENCE CO-CHAIRS Prof. Francisco Triguero Prof. Rafael Morales Universidad de Málaga E.T.S. Ingeniería Informática Dept. Lenguajes y Ciencias de la Computación Bulevar Louis Pasteur, 35 29071 - Málaga (SPAIN) e-mail: icalp2002(a)informatica.uma.es PROGRAM COMMITEE Track A Ricardo Baeza-Yates (U. Chile) Volker Diekert (U. Stuttgart) Paolo Ferragina (U. Pisa) Catherine Greenhill (U. Melbourne) Torben Hagerup (U. Frankfurt) Johan Håstad (KTH, Stockholm) Gabriel Istrate (Los Alamos) Claire Kenyon (U. Paris XI) Der-Tsai Lee (Acad. Sinica, Taipei) Heikki Mannila (Nokia, Helsinki) Elvira Mayordomo (U. Zaragoza) Helmut Prodinger (U. Witwatersrand, South Africa) Jan van Leeuwen(U. Utrecht) Paul Vitányi (CWI, Amsterdam) Peter Widmayer (ETH Zürich) (Chair) Gerhard Woeginger (T.U. Graz) Christos Zaroliagis (U. Patras) Track B Martín Abadi (U. California, Santa Cruz) Roberto Amadio (U. Provence) Gilles Barthe (INRIA-SophiaAntipolis) Manfred Droste (University of Technology Dresden) Cédric Fournet (Microsoft Cambridge) Matthew Hennessy (U. Sussex) (Chair) Furio Honsell (U. Udine) Peter O'Hearn (Queen Mary & W. C. London) Fernando Orejas (U.P.Catalunya) Ernesto Pimentel (U. Málaga) David Sands (Chalmers University of Technology and Göteborg University) Dave Schmidt (U. Kansas) Gheorghe Stefanescu (U. Bucharest) Vasco Vasconcelos (U. Lisbon) Thomas Wilke (U. Kiel)

1 0

RE: closing file handles
by Julian Seward (Intl Vendor) 10 Sep '01

10 Sep '01

| I'm sorry, I had a small error in my code. It should have been: | | >go filelist = mapM go' filelist -- no "do return" | > where go' f = do h <- openFile f ReadMode | > text <- hGetContents h | > let c = head $! text | > return (c `seq` (hClose h `seq` c)) I don't think the "do return" bit matters. If you change the last line to c `seq` (hClose h `seq` return c) is the behaviour changed? J

1 0

Lectureship in Nottingham
by Graham Hutton 10 Sep '01

10 Sep '01

Dear all, We are currently advertising for a new lecturer in Nottingham. There are no particular research areas specified for this position, but applications in the area of the Foundations of Programming research group (www.cs.nott.ac.uk/Research/fop/) would be most welcome. The closing date for applications is Friday 28th September 2001. Graham Hutton ---------------------------------------------------------------------- THE UNIVERSITY OF NOTTINGHAM School of Computer Science and Information Technology Lecturer Applications are invited for the above post in a rapidly-expanding School based at one of the UK's strongest research-led universities. The School was graded 4 in the 1996 Research Assessment Exercise and is now building up its research strengths for a further improvement in grade. This post is part of a steady increase in the size of the School, which was accompanied by a move to new purpose-built accommodation in September 1999. Although the successful candidate will have the opportunity of teaching within their specialist area at undergraduate and postgraduate level, there will also be a requirement to teach general computer science and information technology modules outside of any particular specialisation. Candidates should already have a PhD in computer science, or another closely related discipline, together with strong evidence of existing research work and the potential for future research at Grade 5 level. Outstanding candidates will be welcomed from any area of computer science. Salary will be within the range #20,066 - #31,896 per annum, depending on qualifications and experience. Informal enquiries may be addressed to Professor P H Ford, Head of School, tel: +44 (0)115 951 4251 or Email: Peter.Ford(a)Nottingham.ac.uk. Further information about the School is available on the WWW at: http://www.cs.nott.ac.uk. Further details and application forms are available from the Personnel Office, Highfield House, The University of Nottingham, University Park, Nottingham, NG7 2RD. Tel: +44 (0)115 951 5927. Fax: +44 (0)115 951 5205. Email: Personnel.Applications(a)Nottingham.ac.uk. Please quote ref. LEG/582. Closing date: 28 September 2001. ----------------------------------------------------------------------

1 0

re: ordinary/accumulator recursion
by Randles 10 Sep '01

10 Sep '01

Hi, Im a computer science undergraduate and we are studying haskell as part of our course. I have a question on recursion that i'd like to receive some sort of answer to. The question is to write a function to sum the first n terms in the series: 1/1 + 1/3 + 1/5+ .. + 1/(2n-1) using ordinary recursion and then using accumulator recursion. Please help! Regards Stephanie

2 1

Deriving ..?
by Amit Garg 10 Sep '01

10 Sep '01

Im curious to know how the `deriving' keyword has been implemented, and more so as to how it may be extended for any user defined type class w/o resorting to an external program like DriFt. Thanks! -Amit. ------------------------------------------------------------------- Amit Garg | Office: ACES 6SEo4E Graduate Student | Phone : (512) 232-7875 Computer Sciences | Res : 2000 Pearl St. #207 University of Texas at Austin | Phone : (512) xxx-xxxx Homepage: http://www.cs.utexas.edu/~amitji -------------------------------------------------------------------

2 1

XML
by Steinitz, Dominic J 10 Sep '01

10 Sep '01

dominic.steinitz(a)blueyonder.co.uk 08/09/2001 12:09 To: Dominic Steinitz/HEATHROW/BRITISH AIRWAYS/GB@BRITISH AIRWAYS cc: bcc: Subject: XML If, from Windows, I click on the file: C:\Dom\xml\HaXml-1.02\examples\album.xml then I get the following: The XML page cannot be displayed Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later. ------------------------------------------------------------------------------ Cannot have multiple DOCTYPE declarations. Line 2, Position 11 <!DOCTYPE album SYSTEM "album.dtd" [ ----------^ Is this what should happen? Dominic Steinitz

1 0

closing file handles
by Hal Daume 09 Sep '01

09 Sep '01

I'm working with data spanning a lot of separate files and am having difficulty getting ghc to close the files. I've reduced my code to the following bit of code which should show my problem: >go filelist = do return (mapM go' filelist) > where go' f = do h <- openFile f ReadMode > text <- hGetContents h > let c = head $! text > return (c `seq` (hClose h `seq` c)) basically, you give "go" a list of files and it'll give you the first character from each of these. if i run this with 30-40 files, it's okay. but when i run it with a list of 400 files, i get: *** Exception: resource exhausted Action: openFile Reason: process file table full File: /nfs/isd/marcu/RST-CORPUS-LDC/RSTtrees-WSJ-main-1.0/DATA/wsj_1355.out.dis which doesn't make sense to me, since it should be (as far as i can tell) closing each of the handles (the yucky "c `seq` (hClose h `seq` c)" is my way of making sure that it reads the first character before it closes the file and then makes sure to close the file before returning the character -- if there is a better way, please let me know). if anyone can tell me what my problem is, that would be great! also, along the same lines, are there any good papers on using haskell with large amounts of data? i frequently have problems like this and if there were a unified theory behind dealing with them, it would be great. any pointers would be helpful. thanks! -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

3 3

controlling resource usage
by Richard Uhtenwoldt 07 Sep '01

07 Sep '01

First I must retract what I wrote, ie, >> GHC code can interface with C code, but not as efficiently or as >> flexibly as C or C++ code can interface with C code. --to which Alastair replied: > the foreign function interfaces have been getting >pretty damn good and, if you know your tools > can generate pretty good code. Whilst I don't speak for the >GHC team and can only speak for one of the FFI tools, I think you >should report is as a bug when you find inefficiency of the FFI to be >a bottleneck or that the effort in interfacing to a piece of C code is >way out of proportion to the size of the interface. I was just kind of guessing and surmising, so Alastair's evaluation of FFI is probably the correct one. Alastair: >Haskell's a great programming language for most programming because it >is so good at hiding resource usage from the programmer but since one >of the primary goals of an OS is to control resource usage, this is >exactly what you don't want when you're programming an OS. To kind of summarize, I would like people to voice agreement or disagreement with these next few points. (I'm anticipating wide agreement with all of them.) One of Haskell's strongest points is that more than almost any other PL it allows the programmer to avoid paying attention to the details of memory and cpu usage when memory and cpu usage are unimportant. (But sometimes it is important, so...) For a programmer to learn to control memory and cpu use *well* in Haskell is a very big job --bigger than, eg, learning monads (a *big* stumbling block for the industrial programmers than blow through here and the FP newsgroup) or existential types. So let me talk concretely about that a little, just so people have some words and images to hang their thoughts off of. The way I program in Haskell, I do not concern myself with resource control till I run my program and get empirical evidence that it's too strict (stack overflow or infinite loop) or too lazy, then I ask myself how I can add a ~ to make it lazier or add a seq or rewrite, eg, foo::[(Foo,Bar)]->Baz foo xs = bar xs with foo ((x1,x2):xs) = bar ((x1,x2):xs) (which the mathematician in me wants to consider equivalent in all ways, but sometimes they lead to different resource usage patterns) to make it stricter. Resource control in Haskell is a murky business to me. monads and existential types are the kind of thing I enjoy learning and working with --while not exactly easily and quickly learned, they're "tight" and "mathematical"-- but controlling cpu cycles and memory in Haskell does not have that tight, mathematical flavor I like. Finally, are we all in agreement that it would be a great thing if someone invented a Haskell-like language as good as Haskell at hiding resource usage when resource usage is unimportant, but that made it easier to control resource usage than Haskell does when resource usage is important?

2 1