February 2003 - Haskell

H98 errata
by Ross Paterson 19 Feb '03

19 Feb '03

The definition of getLine given in 8.3: getLine :: IO String getLine = do c <- getChar if c == '\n' then return "" else do s <- getLine return (c:s) is incorrect in view of 7.1: The getLine operation raises an exception under the same circumstances as hGetLine, defined [in] the IO library. ("in" is missing from the published Report.) 21.9.2: The hGetLine computation fails with isEOFError if the end of file is encountered when reading the first character of the line. If hGetLine encounters end-of-file at any other point while reading in a line, it is treated as a line terminator and the (partial) line is returned.

1 0

effect of order of function arguments
by Aaron Denney 19 Feb '03

19 Feb '03

With a recursive function of more than one argument, does it make sense to keep the arguments that tend to remain constant closer to the front? I.e. is this: > interp :: a -> [a] -> [a] > interp y [] = [] > interp y (x:[]) = x:[] > interp y (x:xs) = x:y:interp y xs any better than this: > interp :: [a] -> a -> [a] > interp [] y = [] > interp (x:[]) y = x:[] > interp (x:xs) y = x:y:interp xs y Will any implementations notice interp y x:xs calls interp y, and keep some sort of interp y partial application around? (I don't really expect any effect like this, but even if there were one, I would expect consideration like the fact that "interp constant" is a useful function, while "\x -> interp x const-list" is not so useful to outweigh any such effect. Happily, they don't conflict here. If there is no effect like this, would it make any sense to try to get something similar by hand, and can this actually be done?) -- Aaron Denney -><-

5 4

RE: effect of order of function arguments
by Simon Peyton-Jones 19 Feb '03

19 Feb '03

| GHC used to have an optimisation for static argument like this. It would | turn both of the above programs into a similar form using a local | recursive function: | | interp y xs = interpaux xs | where interpaux [] = [] | interpaux (x:[]) = x:[] | interpaux (x:xs) = x:y:interpaux xs | | GHC doesn't do this anymore. The reason for this is unknown to me. It turned out to be a very minor effect (1-2% of execution time) and hard to tune; with lots of parameters, it's best to make a local function, with just a few it's best to pass the parameters round. S

1 0

RE: Yet another weakly defined bug report
by Simon Marlow 18 Feb '03

18 Feb '03

> The following code runs out of file handles, so I am seeking > enlightenment as to why. > > > -- | add data from a file to the histogram > > addFile :: FiniteMap String Int -> String -> IO (FiniteMap > String Int) > > addFile fm name = do > > x <- readFile name > > return (addHist fm x) > > > > -- | add data from all files in a directory to the histogram > > addDir :: FiniteMap String Int -> String -> IO (FiniteMap > String Int) > > addDir fm dir = do > > dc <- getDirectoryContents dir > > fs <- filterM doesFileExist (map ((dir++"/")++) dc) > > foldM addFile fm fs > > Running addDir on a directory with few hundred files trigs it. > Shouldn't all of each file's contents be consumed by each addFile, and > thus the handle be released? It's not possible to tell from this code whether the readFiles will be fully evaluated or not: it depends on how much evaluation addHist does, and to what extend the result FiniteMap is demanded, amongst other things. These things are always tricky to understand, which is why I recommend not using lazy I/O. File reading is not a pure operation: running out of file descriptors is a good counter-example. Cheers, Simon

6 9

type classes vs. multiple data constructors
by Mike T. Machenry 18 Feb '03

18 Feb '03

I have a type that is as follows: data PlayerState = FugitiveState { tickets :: Array Ticket Int, fHistory :: [Ticket] } | DetectiveState { tickets :: Array Ticket Int, dHistory :: [Stop] } I have a few functions that act on PlayerState. move :: PlayerState -> PlayerState move DetectiveState ... = move FugitivieState ... = I was wondering if it's better to define them as type classes with the operations defined in the class. What do haskellian's do? Oh and if I say Instance Foo Baz where ... and only define a few of the operations in Foo... bdoes Baz take on some default methods? - mike

2 1

WRS 2003 - Second Call for Papers
by Salvador Lucas 17 Feb '03

17 Feb '03

****************************************************************** ********** second call for papers and participation *********** ****************************************************************** Third International Workshop on Reduction Strategies in Rewriting and Programming (WRS 2003) http://www.dsic.upv.es/~rdp03/wrs part of the Federated Conference on Rewriting, Deduction and Programming (RDP 2003) Valencia, Spain, June 8, 2003 ------------------------------------------------------------------ BACKGROUND AND AIMS Reduction strategies in rewriting and programming have attracted an increasing attention within the last years. New types of reduction strategies have been invented and investigated, and new results on rewriting / computation under particular strategies have been obtained. Research in this field ranges from primarily theoretical questions about reduction strategies to very practical application and implementation issues. The need for a deeper understanding of reduction strategies in rewriting and programming, both in theory and practice, is obvious, since they bridge the gap between unrestricted general rewriting (computation) and (more deterministic) rewriting with particular strategies (programming). Moreover, reduction strategies provide a natural way to go from operational principles (e.g., graph and term rewriting, narrowing, lambda-calculus) and semantics (e.g., normalization, computation of values, infinitary normalization, head-normalization) to implementations of programming languages. Therefore any progress in this area is likely to be of interest not only to the rewriting community, but also to neighbouring fields like functional programming, functional-logic programming, and termination proofs of algorithms. The workshop wants to provide a forum for the presentation and discussion of new ideas and results, recent developments, new research directions, as well as of surveys on existing knowledge in this area. Furthermore we aim at fostering interaction and exchange between researchers and students actively working on such topics. The workshop is part of the Federated Conference on Rewriting, Deduction and Programming (RDP 2003) to be held in Valencia (Spain) on June 8, 2003. The workshop is (co-)organized by TU Valencia and TU Wien. TOPICS OF INTEREST Topics of interest include, but are not restricted to: - theoretical foundations for the definition and semantic description of reduction strategies - strategies in different frameworks (term rewriting, graph rewriting, infinitary rewriting, lambda calculi, higher order rewriting and explicit substitutions, conditional rewriting, rewriting with built-ins, narrowing, constraint solving, etc.) and their application in (equational, functional, functional-logic) programming (languages) - properties of reduction strategies / computations under strategies (e.g., completeness, computability, decidability, complexity, optimality, (hyper-)normalization, cofinality, fairness, perpetuality, context-freeness, neededness, laziness, eagerness, strictness) - interrelations, combinations and applications of reduction under different strategies (e.g., equivalence conditions for fundamental properties like termination and confluence, applications in modularity analysis, connections between strategies of different frameworks, etc.) - program analysis and other semantics-based optimization techniques dealing with reduction strategies - rewrite systems / tools / implementations with flexible / programmable strategies as essential concept / ingredient - specification of reduction strategies in (real) languages - data structures and implementation techniques for reduction strategies. SUBMISSIONS We solicit papers on all aspects of reduction strategies in rewriting and programming. Submissions should describe unpublished work, except for survey papers which are explicitly welcome, too. Submissions should not exceed 10 pages (however, survey papers may be longer) and be sent in postscript or PDF format to the PC co-chairs at wrs03(a)logic.at before March 23, 2003. Submissions should include the title, authors' names, affiliations, addresses, and e-mail. Selection of papers by the PC will be based on originality, significance, and correctness. Final versions will be due by May 11, 2003. PUBLICATION Accepted papers will be included in the preliminary workshop proceedings that will be available at the workshop. The final workshop proceedings will be published in the Electronic Notes in Theoretical Computer Science (ENTCS) series of Elsevier. PROGRAM COMMITTEE Sergio Antoy Portland (USA) Zena M. Ariola Eugene (USA) Roberto Di Cosmo Paris VII (France) Juergen Giesl Aachen (Germany) Bernhard Gramlich (co-chair) Wien (Austria) Salvador Lucas (co-chair) Valencia (Spain) Aart Middeldorp Tsukuba (Japan) Ricardo Pe~na Madrid (Spain) Pierre Rety Orleans (France) Eelco Visser Utrecht (The Netherlands) ORGANIZERS Bernhard Gramlich Technische Universitaet Wien Salvador Lucas Universidad Politecnica de Valencia IMPORTANT DATES Deadline for submissions: March 23, 2003 Notification: April 25, 2003 Final version due: May 11, 2003 Workshop: June 8, 2003 FURTHER INFORMATION WRS 2003 website: http://www.dsic.upv.es/~rdp03/wrs WRS 2003 e-mail address: wrs03(a)logic.at RDP 2003 website: http://www.dsic.upv.es/~rdp03 ******************************************************************

1 0

RE: Yet another weakly defined bug report
by Simon Marlow 17 Feb '03

17 Feb '03

> You should do the counting strictly: > > Just n -> case n+1 of n1 -> addToFM f w n1 Careful - that case expression doesn't actually force n to be evaluated. It's exactly equivalent to let n1 = n+1 in addToFM f w n1 You need to use seq to force evaluation. Cheers, Simon

1 0

FM03 CFP- Deadline is approaching
by mailinglist-admin＠fmeurope.org 17 Feb '03

17 Feb '03

Sorry if some of you receive multiple copies of this message. Stefania Gnesi (FM2003 General Chair) ============================================================================== Call for Papers ------------------------------------------------------------------------------ The 12th International FME Symposium Pisa, Italy - September 8-14, 2003 http://fme03.isti.cnr.it - fme03(a)isti.cnr.it ------------------------------------------------------------------------------ FM 2003 is the twelfth in a series of symposia organized 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 as well as industrial users. Formal methods have been controversial throughout their history, and the realization of their full potential remains, in the eyes of many practitioners, merely a promise. Have they been successful in industry? If so, under which conditions? Has any progress been made in dispelling the skepticism that surrounds them? Are they worth the effort? Which aspects of formal methods have become so well established in the industrial practices to loose the "formal method" label in the meanwhile? FM 2003 aims to answer these questions, by seeking contributions not only from the Formal Methods community but also from outsiders and even from skeptical people who are most welcome to explain, document, and motivate the source of their reluctance. We are confident that a wide spectrum of experiences and a loyal contrasting of opinions will foster a better and deeper understanding, if not a wider adoption of Formal Methods. Far from restricting the focus of the conference, however, FM 2003 also welcomes papers with strong theoretical content that establish a connection with the practice of formal methods. Therefore, FM 2003 welcomes papers in all aspects of formal methods for computer systems, including the following: introducing formal methods in the practice of industrial processes (technical, organizational, social, psychological aspects) concerns and risks for potential adopters of formal methods; cost-benefit analysis reports on practical use and case studies (reporting positive or negative experiences) formal methods in hardware and system design reusable domain theories theoretical foundations (specification and modeling, refining, verification, etc.) tool support and software engineering environments for formal methods method integration Papers Full papers should be submitted electronically via the Web by March 7, 2003. Full submission details will be published on the conference web site. Papers will be evaluated by the Program Committee according to their originality, significance, soundness, quality of presentation and relevance with respect to the main issues of the symposium. Papers should have not been submitted elsewhere for publication. Accepted papers will be published in the symposium proceedings in the LNCS series by Springer Verlag. Papers should not exceed twenty pages, although longer papers will be considered if their content justifies it. LNCS format should be used. Please include a short list of keywords on a separate line at the end of the abstract, beginning with the word "Keywords:" in boldface. Other symposium activities In addition to presentations of submitted papers, the symposium will offer half-day or full-day tutorials, one-day or two-days workshops, invited speakers, and tool demonstrations with presentations. Please send your proposals for tutorials/workshops/tool exhibitions to the related chairs by the deadlines indicated below. For full details of what is required, whom to contact, etc, see the web site http://fme03.isti.cnr.it, or send your query to fme03(a)isti.cnr.it. Submission Deadlines March 7, 2003: Papers (firm deadline) March 7, 2003: Workshop/tutorial proposals May 9, 2003: Tool Exhibition proposals June 8, 2003: Papers' final version Acceptance Notifications March 20, 2003: Tutorials/workshops May 9, 2003: Papers June 8, 2003: Tool Exhibition

1 0

CFP: GMAG'03
by Dr. M. Sarfraz 16 Feb '03

16 Feb '03

International Conference on Geometric Modeling & Graphics (GMAG 2003) (Previously, Computer Aided Geometric Design Symposium) in co-operation with IEEE Computer Society JULY 16-18, 2003 London, UK. Aims and Scope: =============== Computer-Aided (CA) techniques for Geometric Modeling (GM) and Computer Graphics (CG) are extremely useful tools in a number of industrial settings. Specifically, the applications of computational geometry and graphical modeling to current problems of designing and manufacturing have grown at a large scale. In addition to its critical importance in the traditional fields of automobile and aircraft manufacturing, shipbuilding, and general product design, more recently, these methods have also proven to be indispensable in a variety of modern industries, including computer vision, robotics, medical imaging, visualization, and even media. The purpose of the GMAG conference is to focus on interdisciplinary methods and affiliate research done among various disciplines with the goal of stimulating views and providing a forum where academicians, researchers, and practitioners can discuss the latest developments linked to Geometric Modeling and Computer Graphics. Papers presenting original research with the theme of "Geometric Modeling and Graphics" are being sought. Scope of the conference topics include (but are not limited to): * Curve and Surface Design * Geometric Modeling * Solid Modeling * Physically Based Modeling * Autonomous Agents * Computer Graphics * Geometric Algorithms * Manufacturing Geometry * Computational Geometry * Reverse Engineering * Computer Aided Design (CAD) * Computer Aided Manufacturing (CAM) * Font Design * Character Design * Multiresolution Methods * Geometric Transformations * Mesh Processing * Shape Abstraction and Modeling * Shape Analysis and Description * Scientific Visualization * Internet Applications * Computer Animation * Rendering * Multimedia * Non Photo-Realistic Rendering * Virtual Reality * Virtual Environments * Illumination Models * Texture Models * Computer Graphics and the Internet (VRML, Java, etc.) * Artificial Intelligence for Computer Graphics * Softwares * Education, Engineering, Medical, and other Applications Important Dates: ================ * 17 January 2003 - Submission of proposal for symposium * 07 March 2003 - Submission of papers and Submission of tutorials * 05 May 2003 - Submission of camera-ready and Early registration closes * 14 June 2002 - Tutorial Registration Cancellation & Refund date (Last day to register for tutorial sessions - Registration after this is subject to availability) * 09 July 2003 - Pre-Registration date * 15 July 2003 - Tutorial Day * 16-18 July 2003 - Conference Days Program Committee ================= Muhammad Sarfraz (Chairman), King Fahd University of Petroleum and Minerals, Saudi Arabia. Varol Akman, Bilkent University, Turkey. Jamaludin Ali, Universiti Sains Malaysia, Malaysia Ebad Banissi, South Bank University, UK. Gordon Clapworthy, De Montfort University, UK. John Cowell, De Montfort University, UK Jinan A. W. Faidhi, Lakehead University, Canada. Stefan Gumhold, University of Tübingen, Germany Hans Hagen, University of Kaiserslautern, Germany Fiaz Hussain, University of Luton, UK. Jihad Mohamad JAAM, University of Qatar, Qatar. Ali Jaoua, University of Qatar, Qatar. Deok-Soo Kim, Hanyang University, Korea. Myoung-Hee Kim, Ewha Womans University, South Korea Sabah M.A. Mohammed, Lakehead University, Canada. Ahmad Nasri, American University of Beirut, Lebanon. Yoshihiro Okada, Kyushu University, Japan Juan Manuel Pena, Universidad de Zaragoza, Spain Abd. Rahni Mt. Piah, Universiti Sains Malaysia, Malaysia Andres Iglesias Prieto, University of Cantabria, Spain Manabu Sakai, Kagoshima University, Japan. Nickolas Sapidis, University of the Aegean, Greece. Leonardo Traversoni, Universidad Autonoma, Mexico. Keith Unsworth,Lincoln University, New Zealand. Markus Wacker, Universitaet Tuebingen, Germany Fujiichi Yoshimoto, Wakayama University, Japan Submission of Papers: ==================== Prospective authors are invited to submit their draft papers electronically by the due date. The length of the Camera-Ready papers (if accepted) will be limited to 7 (IEEE style) pages. Papers must not have been previously published or currently submitted for publication elsewhere. The first page of the draft paper should include: title of the paper, name, affiliation, postal address, E-mail address, telephone number, and Fax number for each author. The first page should also include the name of the author who will be presenting the paper (if accepted) and a maximum of 5 keywords. Proposal for Organizing Technical Sessions Each technical session will have at least 6 paper presentations. The session chairs will be responsible for all aspects of their sessions; including, soliciting papers, reviewing, selecting, etc. THE NAMES OF SESSION CHAIRS WILL APPEAR AS ASSOCIATE EDITORS ON THE COVER OF THE CONFERENCE PROCEEDINGS. Proposals to organize technical sessions should include the following information: name and address (+ E-mail) of proposer, title of session, a 100-word description of the topic of the session, and a short description on how the session will be advertised (in most cases, session proposers solicit papers from colleagues and researchers whose work is known to the session proposer). Mail your proposal to M. Sarfraz; E-mail submissions are preferred. Proposals to organize technical sessions should be submitted as soon as possible. Evaluation Process: =================== Papers will be evaluated for originality, significance, clarity, and soundness. Each paper will be refereed by two to three researchers in the topical area. The Camera-Ready papers will be reviewed by one person. Publication: ============ Attendees will have full access to TWO conferences (IV'2003 & GMAG'2003) at the same time. You are invited to submit a draft paper and/or a proposal to organize a technical session. All accepted papers will be published in the conference proceedings published by IEEE Computer Society Press. In addition to the hardcopy, it is also planned to publish the papers on a CD. EXTENDED VERSIONS OF THE SELECTED PAPERS WILL BE PUBLISHED IN A POST CONFERENCE EDITED BOOK. Web Site: ========= The GMAG'03 web site is: http://www.graphicslink.demon.co.uk/gmag03/. Please visit this site for up-to-date information. Conference Chair: ================= Dr. M. Sarfraz Department of Information and Computer Science, King Fahd University of Petroleum and Minerals, KFUPM # 1510, Dhahran 31261. Saudi Arabia. Tel: +966-03-860-2763 Fax: +966-03-860-2763 and +966-3-860-1562 Email: sarfraz(a)kfupm.edu.sa All queries and Papers should be addressed to: ============================================== Anita D'Pour GraphicsLink...GMAG03 Conference Co-ordinator P.O. BOX 29, HATFIELD, AL9 7ZL, United Kingdom. Tel: (Int. +44) 1707 - 652 224 Fax: (Int. +44) 1707 - 652 247 Email: gmag03(a)graphicslink.demon.co.uk URL: http://www.graphicslink.demon.co.uk/gmag03/

1 0

need help with list comprehension
by Mike T. Machenry 16 Feb '03

16 Feb '03

Hello Everyone, I am writing a program to model a game. I am trying to move 5 players around a graph such that no two players may occupy the same vertex. Players move in a certain order, so to resolve collisions, one must know the order. I'll give a simple example. Imagine a numberline with each number connect to its lesser and greater neighbor. player one (p1) is on vertex 55 and player two (p2) is on vertex 56. p1 must move to 54 because he moves first and p2 is on the only other option. p2 may move to either 55 or 57 because when he moves p1 is off 55. Alright so I am trying to use a list comprehension to model this movement on my graph. I want to build a list of all possible ways the players could move on one particular turn. I have a function (outlets) that gives me the neighbors of a node. This is a first draft function. GameState = GameState Int Int Int Int Int movePlayers :: GameState -> [GameState] movePlayers (GameState p1 p2 p3 p4 p5) = [ (GameState p1' p2' p3' p4' p5') | p1' <- outlets (p1), p2' <- outlets (p2), p3' <- outlets (p3), p4' <- outlets (p4), p5' <- outlets (p5)] This gives me all the possible combinations of moves but does not check to make sure there were no collisions. I tried to write a function to check for a legal state, but it was very unweildy. It had to check the inequality of p1' against p2-p5, then p2' against p1' and p3-p4, and so on. Does anyone know of a better way to do this? Thanks, -mike

2 1