January 2003 - Haskell

A problem about hGetContents
by Nick Name 24 Jan '03

24 Jan '03

I would like to use hGetContents just to retrieve the list of the lines of a file, but if I code a function like: linesFromFile :: FilePath -> IO [String] linesFromFile f = do h <- openFile f ReadMode l <- hGetContents h hClose h return (lines l) I obviously always get the empty list as a result. How should I code the function? Vincenzo -- Teatri vuoti e inutili potrebbero affollarsi se tu ti proponessi di recitare te [CCCP]

4 6

Class Question
by Matthew Donadio 23 Jan '03

23 Jan '03

Hi all, I have yet another question. I think I have too much time on my hands. I have two functions: > rf :: (RealFloat a, Integral b) => [a] -> b -> Complex a > rf x k = ... > cf :: (RealFloat a, Integral b) => [Complex a] -> b -> Complex a > cf x k = ... I would like to add these to the class system so I can create an overloaded version, f. >From my understanding of the Report, the following should work, but I get an error, which I really don't understand. > class (Fractional a) => Floating a where > f :: (Integral b) => [a] -> b -> a > instance (RealFloat a) => Floating a where > f x k = rf x k > instance (RealFloat a) => Floating (Complex a) where > f x k = cf x k hugs98 spits out ERROR "f.lhs":59 - Syntax error in instance head (constructor expected) where line 59 is the first instance declaration. Can anyone give me some guidance, or hints, here? Thanks a million. -- Matthew Donadio (m.p.donadio(a)ieee.org)

2 1

Pictures
by Jan Bergman 22 Jan '03

22 Jan '03

Dear Sirs, In Simon Thompsons book I read on page 27 that a module named Pictures can be downloaded from your web page. I cannot find that module. Where is it? Best regards Jan Bergman

1 0

Proposal Proposal: haskell-gui addendum to haskell standard
by David Sankel 22 Jan '03

22 Jan '03

Hello Everyone, I believe that haskell would have great benifit from a platform independant specification for a graphical user interface module or set of modules. I've been blessed with a lot of time on my hands so I'd be willing to organize this project if needed. Since there are several working haskell gui libraries out there, I would like this to be a collaboration project with those who are experienced in this area. Input and ideas from users would also be a part of the collaberation. The goal would be a specification much like the haskell report that could be freely implimented and a reference impementation. This is an informal proposal for a proposal and would like to get some feedback for the following ideas. (please reply to gui(a)haskell.org) 1. Platform independance: The QT widget library is a stunning example of how platform independance is achievable without sacraficing speed. I am not suggesting that we build haskell-gui off of QT but might use major components of it as a model. Eventually, the library could have three backends; the Windows API, the X API (or gtk perhaps?), and the Mac API (the name illudes me at the moment). 2. Signals support: Having a signals mechanism is essential for large gui projects. 3. Dynamic widgets: All widgets should have dynamic size and should have the ability to be resized by the measurement of their contents or their parents. This could be done in a way similar to QT widgets. 4. GUI GUI builder: Widgets should be flexible enough to have the ability to be incorporated in a GUI GUI builder program, such as QT designer. The storage for a GUI builder might be direct Haskell code or some intermediate format. 5. OpenGL incorporation: haskell-gui should have some sort of OpenGL widget as OpenGL is the most standardized and multiplatform graphical library availible. Perhaps the hgl software could be incorporated in this aspect of haskell-gui. 6. Custom Widgets: It should be easy for one to create his or her own custom widgets from scratch using Haskell code or by some modification of the standard ones. Please give your feedback and suggestions for this project proposal proposal. If there is enough interest, I'll get this thing started. Kudos, David J. Sankel Head Consultant Electron Consulting (www.electronconsulting.com)

3 2

Question about a Function getTime
by Cesar Augusto Acosta Minoli 22 Jan '03

22 Jan '03

2 1

RE: Arrays vs Lists and Specialization
by Simon Peyton-Jones 22 Jan '03

22 Jan '03

Matthew | Many spectral estimation routines are defined in terms of special | matrices (ie, Toeplitz, etc). Arrays defined recursively by list | comprehensions make it easy to implement algorithms like Levinson-Durbin | recursion, and they look very similar to the mathematical definitions: | | > levinson r p = (array (1,p) [ (k, a!(p,k)) | k <- [1..p] ], realPart (rho!p)) | > where a = array ((1,1),(p,p)) [ ((k,i), ak k i) | k <- [1..p], i <- [1..k] ] | > rho = array (1,p) [ (k, rhok k) | k <- [1..p] ] | > ak 1 1 = -r!1 / r!0 | > ak k i | k==i = -(r!k + sum [ a!(k-1,l) * r!(k-l) | l <- [1..(k-1)] ]) / | rho!(k-1) | > | otherwise = a!(k-1,i) + a!(k,k) * (conjugate (a!(k-1,k-i))) | > rhok 1 = (1 - (abs (a!(1,1)))^2) * r!0 | > rhok k = (1 - (abs (a!(k,k)))^2) * rho!(k-1) | | OK, my question then has to do with the efficiency of lists versus | arrays. Do the latest compilers handle handle arrays efficiently, or | are lists really the way to go? If there is a performace difference, is | it generally big enough to warrant rewriting algorithms? Do not rewrite it! This is a textbook application of Haskell arrays, and they should work beautifully. If not, we should fix it. Using lists will probably be much *less* efficient than arrays. People often use arrays with algorithms derived from imperative programming, which assume update-in-place. They use (\\) for each element, which copies the entire array, and get terrible performance. Haskell arrays are designed to be build en-bloc, as you are doing it. Your programs are lovely, and will not do redundant array copying. It is, however, possible that GHC fails to deforest away all the intermediate lists in the array comprehensions, but I think it does a reasonable job. You can use -ddump-simpl to see. | A related question is how is specilization handled in arrays with lazy | evaluation. In the definition of levinson above, the a array is defined | in terms of the ak function. By doing this, you save some horizontal | space, but it also unburdens the programmer from tracking the recursive | dependencies. a!(k,k) is needed before a!(i,j) can be calculated, but | lazy evaluation takes care of this. Yes. The efficiency penalty is that every element is built as a thunk and only later evaluated on demand. | If the above function is | specialized for r::Array Int (Complex Double) and p::Int, would I be | correct to say that the final value of the function would be unboxed, | but all intermediate values wouldn't? No, the function returns an array, which is always boxed. Its *elements* may be unboxed, but only if you, the programmer, specify them to be unboxed. GHC will not unbox array elements automatically, because that makes them strict, and that changes the semantics. To use unboxed arrays, you need the UArray library (documented in GHC's libraries). If the algorithm does not use laziness, you can often unbox array elements just by changing "Array" to "UArray" in the types. Easy. But that makes it strict, and that may make your algorithm fail. No magic here. | Now, in some cases, a user may | need all of the model orders from 1..p. This is handled easilly enough | by just changing the first line. to | | > levinson r p = (a, fmap realPart rho) | | Would the a matrix in the tuple be unboxed with specilization? Not sure what you mean here, but I don't think so. | If anyone is interesting in what I have put together, I will be making | everything public sometime next week. I have a lot of algorithms | implemented, but I need to clean up the documentation a bit (well, a | lot). Would you like to write it up as a paper for the Journal of Functional Programming? By the way, do you know of David Goblirsch's work http://delivery.acm.org/10.1145/330000/326801/p425-goblirsch.pdf?key1=32 6801&key2=1086223401&coll=GUIDE&dl=GUIDE&CFID=7058054&CFTOKEN=55810940 I'm not sure where he is now. Simon

3 2

CFP: DALT'03 - 1st Int. Workshop on Declarative Agent Languages and Technologies
by João Alexandre Leite 22 Jan '03

22 Jan '03

[We apologize if you receive multiple copies of this message.] =========================================================== F I R S T C A L L F O R P A P E R S DALT 2003 First International Workshop on Declarative Agent Languages and Technologies Melbourne, Australia July 2003 http://centria.di.fct.unl.pt/~jleite/dalt03/index.htm In conjunction with AAMAS 2003 2nd International Conference on Autonomous Agents and Multi-Agent Systems http://www.aamas-conference.org/ Submission: 11 of April, 2003 Post-Proceedings by Springer-Verlag (LNAI) =========================================================== TECHNICAL DESCRIPTION Agent metaphors and technologies are ever more adopted to harness and govern the complexity of today's systems. As a consequence, the growing complexity of agent systems calls for models and technologies that promote system predictability, and enable feature discovery and verification. Recent advances in the area of logics and formal methods make declarative languages and technologies a mostly promising approach to the modeling and engineering of complex agent systems. DALT aims at fostering a discussion forum to export, on the one hand, such techniques into the broader community of agent researchers and practitioners and, on the other hand, to bring in the issues of real-world, complex, and possibly large-scale agent system design in the perspective of formal methods and declarative technologies. DALT 2003 will take place in Melbourne, Australia, in conjunction with AAMAS, the 2nd International Conference on Autonomous Agents and Multi-Agent Systems. Topics of interest include, but are not limited to: * Declarative agent communication and coordination languages * Knowledge-based and knowledge-intensive MAS * Modeling of agent rationality * Declarative approaches to the engineering of MAS * High level agent specification languages * Practical aspects of declarative agent programming and implementation * Formal methods for the specification and verification of MAS * Computational logics in MAS * Argumentation and dialectical systems in MAS * Declarative description of contracts and negotiation issues in MAS * Lessons learned from the design and implementation of MAS * Declarative paradigms for the combination of heterogeneous agents * Constraints and MAS * Declarative representation of policies and security in MAS SUBMISSIONS We welcome and encourage the submission of high quality, original papers, which are not simultaneously submitted for publication elsewhere. Papers should be written in English, formatted according to the Springer LNCS style, which can be obtained at (http://www.springer.de/comp/lncs/authors.html) and not exceed 16 pages including figures, references, etc. Electronic submissions, in PostScript (PS) or Portable Document Format (PDF), should be sent to jleite(a)di.fct.unl.pt. IMPORTANT DATES * Submission, 11 of April, 2003 * Notification, 6 of May, 2003 * Camera Ready, 16 of May, 2003 PROCEEDINGS To encourage and promote the discussion, early and final versions of the accepted papers will be available online, at the workshop's web page, as soon as they are available. A printed volume with the proceedings will be available at the workshop. Authors of papers presented at the workshop will be asked to extend their contributions, possibly incorporating the results of the workshop discussion, to be included in the workshop post-proceedings. Post-proceedings will be published by Springer-Verlag as a volume of the Lecture Notes on Artificial Intelligence series (http://www.springer.de/comp/lncs/index.html) PROGRAM COMMITTEE * Rafael Bordini, The University of Liverpool, UK * Jeff Bradshaw, The University of West Florida, FL, USA * Antonio Brogi, Università di Pisa, Italy * Stefania Costantini, Università degli Studi di L'Aquila, Italy * Yves Demazeau, Institut IMAG, Grenoble, France * Jürgen Dix, The University of Manchester, UK * Toru Ishida, Kyoto University, Japan * Catholijn Jonker, Vrije Universiteit Amsterdam, The Netherlands * Antonis Kakas, University of Cyprus, Cyprus * Daniel Kudenko, University of York, UK * Alessio Lomuscio, King's College, London, UK * Viviana Mascardi, DISI, Genova, Italy * Paola Mello, Università di Bologna, Italy * John Jules Ch. Meyer, Universiteit Utrecht, The Netherlands * Charles L. Ortiz, SRI International, Menlo Park, CA, USA * Sascha Ossowski, Universidad Rey Juan Carlos, Madrid, Spain * Luís Moniz Pereira, Universidade Nova de Lisboa, Portugal * Jeremy Pitt, Imperial College, London, UK * Ken Satoh, National Institute of Informatics, Tokyo, Japan * Michael Schroeder, City University, London, UK * Onn Shehory, IBM Research Lab in Haifa, Israel * Carles Sierra, Spanish Research Council, Barcelona, Spain * V.S. Subrahmanian, University of Maryland, MD, USA * Francesca Toni, Imperial College, London, UK * Wiebe van der Hoek, The University of Liverpool, UK * Franco Zambonelli, Università di Modena, Italy ORGANIZING COMMITTEE Co-chairs: João Alexandre Leite (Contact Person) Universidade Nova de Lisboa jleite(a)di.fct.unl.pt Andrea Omicini Università di Bologna aomicini(a)deis.unibo.it Leon Sterling The University of Melbourne leon(a)cs.mu.oz.au Paolo Torroni Università di Bologna ptorroni(a)deis.unibo.it

1 0

RE: Arrays vs Lists and Specialization
by Simon Peyton-Jones 22 Jan '03

22 Jan '03

| You could check out SAC. SAC is a functional language specialized for | arrays, with restrictions in the language to ensure efficient compilation. | The SAC compiler can apparently do a very good job on scheduling/memory | allocation as to optimize for cache performance: this is an important issue | to get performance in array computations that I believe current Haskell | implementations do not bother much about. Yes, SAC is an outstanding and not-well-enough-known language. Beats FORTRAN, which is jolly impressive. Does not do recursively-defined arrays, though, I think. Simon

1 0

Arrays vs Lists and Specialization
by Matthew Donadio 22 Jan '03

22 Jan '03

Hi all, I'm sorry if this topic has been rehashed a lot, but I poked around in the mailing list archive, and didn't find what I was looking for. I currently have some free time on my hands, and have been implementing some digital signal processing and spectral/frequency estimation algorithms along with the needed matrix routines in Haskell. For those unfamiliar with this field, most algorthms are defined in textbooks in terms of indexing through discrete sequences. For example the implementation of cross-correlation > rxy x y k | k >= 0 = sum [ x!(i+k) * (conjugate (y!i)) | i <- [0..(n-1-k)] ] > | k < 0 = conjugate (rxy y x (-k)) > where n = snd (bounds x) + 1 looks very similar to the textbook definition if one uses arrays. A definition using lists would probably use drop, map, and zipWith, and look nothing like the definitions found in the standard texts. Many spectral estimation routines are defined in terms of special matrices (ie, Toeplitz, etc). Arrays defined recursively by list comprehensions make it easy to implement algorithms like Levinson-Durbin recursion, and they look very similar to the mathematical definitions: > levinson r p = (array (1,p) [ (k, a!(p,k)) | k <- [1..p] ], realPart (rho!p)) > where a = array ((1,1),(p,p)) [ ((k,i), ak k i) | k <- [1..p], i <- [1..k] ] > rho = array (1,p) [ (k, rhok k) | k <- [1..p] ] > ak 1 1 = -r!1 / r!0 > ak k i | k==i = -(r!k + sum [ a!(k-1,l) * r!(k-l) | l <- [1..(k-1)] ]) / rho!(k-1) > | otherwise = a!(k-1,i) + a!(k,k) * (conjugate (a!(k-1,k-i))) > rhok 1 = (1 - (abs (a!(1,1)))^2) * r!0 > rhok k = (1 - (abs (a!(k,k)))^2) * rho!(k-1) This could be rewritten for lists, but would probably need to be defined in terms of an aux. recursive function, which destroys the simplicity of the above definition. OK, my question then has to do with the efficiency of lists versus arrays. Do the latest compilers handle handle arrays efficiently, or are lists really the way to go? If there is a performace difference, is it generally big enough to warrant rewriting algorithms? A related question is how is specilization handled in arrays with lazy evaluation. In the definition of levinson above, the a array is defined in terms of the ak function. By doing this, you save some horizontal space, but it also unburdens the programmer from tracking the recursive dependencies. a!(k,k) is needed before a!(i,j) can be calculated, but lazy evaluation takes care of this. If the above function is specialized for r::Array Int (Complex Double) and p::Int, would I be correct to say that the final value of the function would be unboxed, but all intermediate values wouldn't? Now, in some cases, a user may need all of the model orders from 1..p. This is handled easilly enough by just changing the first line. to > levinson r p = (a, fmap realPart rho) Would the a matrix in the tuple be unboxed with specilization? If anyone is interesting in what I have put together, I will be making everything public sometime next week. I have a lot of algorithms implemented, but I need to clean up the documentation a bit (well, a lot). Thanks. -- Matthew Donadio (m.p.donadio(a)ieee.org)

2 1

ANNOUNCE: HOpenGL 1.04 released
by Sven Panne 21 Jan '03

21 Jan '03

HOpenGL, a Haskell binding for OpenGL and GLUT version 1.04 I am pleased to announce the fifteenth release of the Haskell binding for GL 1.2.1 / GLU 1.3 / GLUT 3.7beta. It offers easy access to *the* industrial strength 3D graphics API and a GUI toolkit. More details about HOpenGL can be found at http://haskell.org/HOpenGL After quite some time, this is not only a bugfix release, but offers some real improvements and new features. The changes include: * The GLUT binding has been completely rewritten and includes extensive documentation. * The API for quadrics and tessellation has been made much easier and more Haskell-like. * The configuration process has been improved once again. * The license is now BSD-like. * At least GHC 5.04.x is needed for building HOpenGL. * NURBS has been temporarily disabled (will be fixed soon). As always, feedback and/or patches are highly welcome. Have fun! Sven

1 0