- Haskell - Haskell.org

RE: H98: Ix class
by Simon Peyton-Jones 11 Sep '01

11 Sep '01

| Just to clarify, do we still require identities (1) and (3) | below (pasted from the Library report and numbered)? That | is, is range obliged to yield its results in strict index | order? [This rules out Ix instances that do, e.g., blocked | iteration unless the array itself is also re-blocked. | Reblocking the array itself is arguably a good idea, but may | not be what we expect...] | | 1) range (l,u) !! index (l,u) i == i -- when i is in range | 2) inRange (l,u) i == i `elem` range (l,u) | 3) map index (range (l,u)) == [0..rangeSize (l,u)] I was not proposing to remove these identities. Should I? Simon

1 0

Re: H98: Ix class
by Jan-Willem Maessen 11 Sep '01

11 Sep '01

Simon PJ asks: > Does anyone want to argue that having Ord as a superclass of Ix is So > Bad > that it Absolutely Must Be Removed? Nope. If there's no natural ordering I expect the derived ordering will be used in practice. Occasionally messy, but it keeps the old code going. Just to clarify, do we still require identities (1) and (3) below (pasted from the Library report and numbered)? That is, is range obliged to yield its results in strict index order? [This rules out Ix instances that do, e.g., blocked iteration unless the array itself is also re-blocked. Reblocking the array itself is arguably a good idea, but may not be what we expect...] 1) range (l,u) !! index (l,u) i == i -- when i is in range 2) inRange (l,u) i == i `elem` range (l,u) 3) map index (range (l,u)) == [0..rangeSize (l,u)] -Jan-Willem Maessen Eager Haskell Project jmaessen(a)mit.edu

1 0

ANN: Gtk+HS 0.11.5
by Manuel M. T. Chakravarty 11 Sep '01

11 Sep '01

I am pleased to announce version 0.11.5 of Gtk+HS, the Haskell binding for the GUI toolkit GTK+. This is the first beta release and the first release that comes with pre-build binaries. The binding is not complete yet, but it is sufficient for applications with GUIs of medium complexity. The underlying toolkit, GTK+, implements a mature, high-end widget set, which forms the basis of the Gnome desktop environment, and is used in cutting edge open source applications, such as the Gimp, Gnumeric, and Abiword. Gnome (and, thus, GTK+) is not only one of the two main desktop environments for Linux, but has also been selected by Sun as the new standard desktop for Solaris. Moreover, there is a port of GTK+ available for Win32. The present distribution includes an example application (The Boolean Editor) that demonstrates how GTK+ can be used from Haskell. It illustrates concepts, such as callbacks, the handling of global GUI state, and synchronisation between the different windows of an application. The code is available directly from the Web page without need to download the complete release. Portability: I tested this release with GHC on GNU/Linux; however, it should work equally well on any other Unix platform that is supported by GHC. Moreover, it should, after some fiddling with makefiles, also work with NHC98, but I haven't got around to testing that yet. With the GTK+ port for Windows, Gtk+HS should in principle also be usable on Windows. I am not keen on trying the latter myself, but I would welcome any patches that are necessary to make it work. Gtk+HS includes code contributions from a number of people. See <http://cvs.gnome.org/lxr/source/gtk%2bhs/AUTHORS> for details. More information (including screenshots!) as well as source and binary packages are available from http://www.cse.unsw.edu.au/~chak/haskell/gtk/ Happy Hacking! Manuel

2 1

H98: Ix class
by Simon Peyton-Jones 11 Sep '01

11 Sep '01

Folks, (esp Matt, Jan-Willem) Back from ICFP, I have resumed my increasingly small circles around the Revised Haskell 98 Report. In an earlier message (which I enclose for your convenience) I proposed to: a) Remove Ord from Ix's superclasses b) Add rangeSize to Ix's methods (with a suitable default method) As we implemented these changes we discovered that change (a) actually breaks existing programs. Of course it does: now you have to add Ord to the signature of any function that compares indices. This really does happen (for example, it happens even in the code for the Array library in the Report). I should have realised this before, but I therefore withdraw proposal (a). It now looks like a perhaps-desirable, but definitely un-forced change, and that goes beyond my remit. However (b) doesn't break anything, I think, so I propose to let it stand. (The two are independent I think.) Does anyone want to argue that having Ord as a superclass of Ix is So Bad that it Absolutely Must Be Removed? Simon -----Original Message----- From: Simon Peyton-Jones Sent: 17 May 2001 17:52 To: Matt Harden; Haskell list Subject: RE: Ix class I rather agree with Matt's message below. I'm desperately trying NOT to change the H98 libraries, but this is a very non-disruptive change, as he points out, and it does lift two apparently-unnecessary restrictions. a) Remove Ord from Ix's superclasses b) Add rangeSize to Ix's methods Does anyone have any thoughts about this. (We made a similar change to Random, adding a method.) Simon | -----Original Message----- | From: Matt Harden [mailto:matth@mindspring.com] | Sent: 16 May 2001 00:43 | To: Haskell list | Subject: Ix class | | | Hello, | | I am working on an Ix instance for one of my types and | finding it rather restrictive. For me it would be useful to | have rangeSize be defined in the Ix class (with a default | definition of course), so that it can be overridden. | | Also, does anybody know why Ix derives from Ord? It seems to | me this is an unnecessary limitation on the types that can be | instances of Ix. I cannot think of a reason why the | implementation of anything in the Ix or Array modules would | require that every Ix be an Ord (with a minor exception -- | see below). If an implementation is using a comparison on an | Ix type, chances are it should be using inRange or comparing | (index bnds x) with (index bnds y) instead. | | One change would have to be made in the Array module if Ord | is removed from Ix: | instance (Ix a, Eq b) => Eq (Array a b) where | a == a' = assocs a == assocs a' | instance (Ix a, Ord b) => Ord (Array a b) where | a <= a' = assocs a <= assocs a' | | would become: | instance (Ix a, Eq a, Eq b) => Eq (Array a b) where | a == a' = assocs a == assocs a' | instance (Ix a, Ord a, Ord b) => Ord (Array a b) where | a <= a' = assocs a <= assocs a' | | As I said, I think this is a very minor issue. | | I believe that making these changes in the standard would not | impact existing programs in any way. Could these changes be | considered as a possible "typo" to be fixed in the Library Report? | | | P.S. In case anybody's interested, here's why I want to override | rangeSize: | | > newtype Honeycomb = Hx (Int,Int) deriving (Eq,Show,Ord) | > | > indexError = error "Index out of range" | > | > instance Ix Honeycomb where | > range (Hx b1, Hx b2) = | > [Hx x | x <- range (b1,b2), isHexIx x] | > inRange (Hx b1, Hx b2) (Hx x) = | > inRange (b1,b2) x && isHexIx x | > index (Hx b1, Hx b2) (Hx x) = | > let i = index (b1,b2) x in | > if isHexIx x then i `div` 2 else indexError | > | > isHexIx :: (Int,Int) -> Bool | > isHexIx (x,y) = x `mod` 2 == y `mod` 2 | | This implements a honeycomb or hexagonal tiling for a maze | generating program. The honeycomb is superimposed on a grid | such that only every other square is "active", corresponding | to a particular hexagon in the honeycomb. It's similar to a | checkers game, where only the dark squares are used. | | I would like _any_ pair of Ints to be an acceptable boundary | for the honeycomb, not just the ones that represent valid | indexes. For example, (Hx (0,0), Hx (15,12)) should be a | valid set of bounds. The current definition of rangeSize | makes this impossible, which is why I would like to override | it. By the way, the Library Report does not explicitly say | that the bounds have to both be valid indexes, though it does | imply this with the sample definition of rangeSize. | | Thanks, | Matt Harden | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell | _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

2 1

RE: Hiding non-existent entities
by Simon Peyton-Jones 10 Sep '01

10 Sep '01

Simon and Manuel propose that it should be an error for an import statement to hide something which isn't exported by the module being imported. This is a point on which I am willing to be swayed. It's a matter of taste, and really it doesn't matter what we decide provided we decide something. I'll adopt Simon & Manuel's view unless enough people yell. Frankly, I don't think it is worth a hullabaloo. Simon | -----Original Message----- | From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au] | Sent: 30 August 2001 07:20 | To: Simon Marlow | Cc: haskell(a)haskell.org | Subject: Re: Hiding non-existent entities | | | "Simon Marlow" <simonmar(a)microsoft.com> wrote, | | > The Haskell 98 errata page currently contains this item | related to a | > hiding clause on an import declaration which refers to a | non-existent | > entity: | > | > [Aug 2001] Page 66, Section 5.3, Import Declarations, | > numbered item 2. Add "It is not an error to hide an entity | > that is not, in fact, exported by the imported module, although | > compilers are encouraged to flag a warning in this case." (This | > is different from what I proposed by email, which made this case | > an error, but it allow a bit more flexibility as modules change.) | > | > IMO allowing a hiding clause to refer to a non-existent entity is a | > bit odd. Haskell doesn't have any other features like this: it's | > always an error to refer to an entity that isn't defined anywhere, | > even if the reference is otherwise harmless. Does anyone else have | > any opinions on this? | | I agree with you. | | Cheers, | Manuel | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

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