- Haskell - Haskell.org

TYPES 06: Call for papers
by Wouter Swierstra 07 Nov '05

07 Nov '05

TYPES 2006 Main Conference of the Types Project Nottingham, UK, 18-24 April 2006 http://www.cs.nott.ac.uk/types06/ This is the latest meeting in a series that started 1992, the last conference was in December 2004 in Paris. The topic of the meeting is formal reasoning and computer programming based on Type Theory : languages and computerised tools for reasoning, and applications in several domains such as analysis of programming languages, certified software, formalisation of mathematics and mathematics education. TYPES 2006 is colocated with TFP 2006 (Trends in Functional Programming) and we plan to hold a joint session on Dependently Typed Programming. The conference takes place at Jubilee campus of the University of Nottingham, on-site accomodation will be available together with the registration. For more information see: http://www.cs.nott.ac.uk/types06/ We will open registration early next year. You will be able to submit your talk and abstract together with your registration. We will try to accomodate all talks which fit into the scope of the TYPES project. There will also be invited lectures. Please direct all emails related to TYPES 2006 to types06(a)cs.nott.ac.uk Cheers, The Organisation Comittee Thorsten Altenkirch, James Chapman, Conor McBride, Peter Morris and Wouter Swiestra This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

why don't we have const Ptrs?
by David Roundy 06 Nov '05

06 Nov '05

Hello all, I was thinking this morning as I lay on the floor (where I sleep) about static typechecking, and how much more wonderful Haskell is than any other language, when it occurred to me that when working with pointers, Haskell actually has *less* static typechecking than C or C++. It was a very disturbing thought, so much so that I was almost compelled to arise early to place this question before this learned audience. Why is it that in C++ I can write void strcpy(char *dest, const char *src); but in Haskell I must import this function as > foreign import ccall unsafe "static string.h strcpy" > strcpy :: Ptr CChar -> Ptr CChar -> IO () and lose that wonderful information that the function doesn't modify the contents of its second argument? One could pretty easily create a ConstPtr type which one could peek into, but not poke to, but then you'd have to explicitely convert a Ptr into a ConstPtr when passing it as an argument. That feels a bit silly. One could get around this by introducing a class to get around this > class ReadablePtr p where > peek :: p a -> IO a > peekOff ... and then make both Ptr and ConstPtr instances of this class, but this still seems like a very hackish solution. Moreover, I'd like to be able to have const objects quite apart from Ptrs, such as a const Handle, which I can read from, but cannot write to, or a const IORef--and we wouldn't want to leave out const ForeignPtrs. Of course, even reading affects a Handle's internal state, so one would need to be explicit about what "const" indicates. But it seems to me that in the IO world there are a whole slew of "things that refer to other things" which could all be grouped together. And a "const" attribute ought to be derived, so that if I create a data type > data FooPtr = FooPtr String (Ptr Foo) one should ideally be able to automatically understand that a const FooPtr holds a const (Ptr Foo). One could go further, at least when dealing with Ptrs, and create a way of handling "restricted" pointers--which we could interpret as a const pointer to an object that cannot be changed by anyone else either. One could safely create restricted pointers with a function of the type > mallocRestrictedPtr :: (Ptr a -> IO ()) -> RestrictedPtr a which would allow one to ensure at the typechecking level that RestrictedPtrs point to memory that cannot be modified. There's still some unstafety involved, in that you could read out of bounds, but you would know that apart from that possibility the contents of a RestrictedPtr truly will never change. So my question is, how would one implement such an "annotation" extension? I'd like to be able to pass a (Ptr a) as a (Const (Ptr a)) without an explicit typecast, since the Const really isn't changing the type of the pointer, it's just marking it as one that can't be modified. A function that accepts a (Const (Ptr a)) should also accept a (Restricted (Ptr a))--but Restricted pointers are really just pudding, as they only differ from Const pointers in what optimizations are allowed. On the other hand, it's not just compiler optimizations that they would allow, but also user-code optimizations, which could be much more useful. They also have the advantage of making certain unsafe functions safe. The hard part seems to be the lack of a conversion. One could quite easily implement a > data Const a = Const a -- this constructor is *not exported* > toConst :: x -> Const x > unsafeAccessConst :: Const x -> x > peek :: Const (Ptr a) -> IO a > peekOff ... etc, and everything would work fine, except that you'd always need to explicitely convert from Ptr to Const Ptr. Perhaps one could make Const be a class as well as a data type: > class (Const a) x where > toConst :: x -> Const a > instance (Const x) x where > toConst = Const > instance (Const x) (Const x) where > toConst = id and then one could write code like > peek :: Const (cp a) => cp a -> IO a which would move the typecasting burden out of the calling function and into the function that accepts a const argument. Perhaps this would be sufficient, as many data types have only a limited number of "primitive const" functions, and all the other "const" functions wouldn't actually need to call toConst. What this doesn't allow is deriving of constness, so that a Const ForeignPtr would automatically hold a Const Ptr. This whole class+data type scheme seems like it might be useful, but is pretty ugly. Is there a better way this could be done? Might one be able to extend the language so that one could add "attribute" such as Const to data type without changing the the type itself (which would be analogous to what one does in C/C++)? -- David Roundy http://www.darcs.net

8 7

ANNOUNCE: Gtk2Hs version 0.9.10 released
by Duncan Coutts 05 Nov '05

05 Nov '05

Gtk2Hs - A GUI Library for Haskell based on Gtk+ Version 0.9.10 is now available from: http://haskell.org/gtk2hs/download/ An installer for Windows is available. A package is available for Gentoo. Packages for other platforms should become available soon (hopefully including Fedora Core, Debian, Darwin, FreeBSD and OpenBSD). Changes since 0.9.9: * New bindings for the cairo vector graphics library. This provides a easy-to-use vector graphics API (using a PDF-style drawing model) with high quality output for multiple backends (screen, print and image files). * Completion of Pango, the text layout and rendering engine of Gtk +. We now provide all functions that end users should ever need for rendering text, ranging from type-setting whole paragraphs down to breaking up attributed text into several runs. All offsets into Haskell strings are transparently translated into UTF-8 offsets used in Pango, thereby alleviating much of the grief of dealing with Unicode. * new Gtk+ 2.8 APIs are bound * many bugs fixed * various minor documentation improvements * an installer for Windows is available again * the mozembed HTML rendering component can now be built against the FireFox libraries if the appropriate developer files are present. Other news since the last release announcement: * Paolo Martini won a $4500 grant under the Google Summer of Code programme for a project to add bindings for the cairo vector graphics library to Gtk2Hs. * Gtk2Hs is being used as part of the practical element of Functional Programming courses at the University of Oxford in England and the University of Jyväskylä in Finland. Gtk2Hs feature highlights: * automatic memory management * Unicode support * nearly full coverage of Gtk+ 2.8 * bindings for the cairo vector graphics library * support for the Glade visual GUI builder * bindings for several Gnome modules: GConf, Gnome's system for storing app preferences SourceView, code editor widget with syntax highlighting the Mozilla browser rendering engine in a widget * extensive API reference documentation * multi-platform support with native look * LGPL licence Platforms and requirements: * builds from source on Linux, Windows, MacOS X, FreeBSD, OpenBSD and Solaris * builds with GHC 6.4.x, 6.2.x, 6.0.x and 5.04.x * works with Gtk+ version 2.0 through to 2.2, 2.4, 2.6 and 2.8 * optional cairo support requires cairo 1.0 or later, however using cairo in conjunction with Gtk+ requires Gtk+ 2.8.x or later * optional Gnome support requires Gnome 2.0 or better * optional Mozilla support requires Mozilla 1.4 or FireFox 1.0 or later with the appropriate development files. Goals for the 1.0 release: * a stable API for the 1.0.x series * greater coverage of the Gtk+ API (we're about 90% there now) * support for the OpenGL 3D rendering API * introductory and other tutorials * packages for all popular platforms Please report all problems to gtk2hs-devel(a)sourceforge.net Contributions and feedback are also most welcome. To lower the barrier to contributions, the development version of Gtk2Hs is now available via darcs: darcs get http://haskell.org/gtk2hs/darcs/gtk2hs Duncan (on behalf of the Gtk2Hs team)

1 0

POPL 2006 Call for Participation
by David Walker 04 Nov '05

04 Nov '05

********************************************************************* * ACM SIGPLAN-SIGACT Symposium * * on * * Principles of Programming Languages * * * * January 11-13, 2006 * * Charleston Place Hotel * * Charleston, South Carolina * * * * Call for Participation * * * * http://www.cs.princeton.edu/~dpw/popl/06/ * ********************************************************************* Important dates * Early Registration Deadline: December 10, 2005 * Hotel Reservation Deadline: December 10, 2005 * Conference: January 11-13, 2006 Scope The annual Symposium on Principles of Programming Languages is a forum for the discussion of fundamental principles and important innovations in the design, definition, analysis, transformation, implementation and verification of programming languages, programming systems, and programming abstractions. Both experimental and theoretical papers on principles and innovations are welcome, ranging from formal frameworks to reports on practical experiences. Invited Speakers * James McKinna, St Andrews University * Martin Odersky, Ecole Polytechnique Fédérale de Lausanne * Tim Sweeney, Epic Games Inc Conference Registration Registration is now open! To register, please go to our registration site at (http://www.regmaster.com/popl2006.html) Early registration for a reduced fee is available until December 10, 2005. Don't delay! Hotel Room Reservation We recommend staying at the Charleston Place Hotel, which is where the conference will be held. Our group rate for the hotel is $155/night. (This does not include the 12.5% state tax on hotels.) Please mention the group name "ACM POPL 2006 Conference" when reserving a room. You may reserve rooms by phone, fax or email, but not using the web. * phone: (800) 831-3490 -- Staffed Monday through Friday, 8:00 am to 6:00 pm * fax: (843) 724-7215 * email: groupres(a)charlestonplace.com The hotel website is http://www.charlestonplace.com/web/ocha/ocha_a1a_splash.jsp Student Attendees Students who have a paper accepted for the conference are offered student membership of SIGPLAN free for one year. As members of SIGPLAN they may apply for travel fellowships from the PAC fund. Conference Chair Greg Morrisett Harvard University 33 Oxford Street Cambridge, MA 02138 USA greg at eecs dot harvard dot edu Program Chair Simon Peyton Jones Microsoft Research Ltd, 7 JJ Thomson Ave, Cambridge CB3 0FB, UK simonpj(a)microsoft.com Program Committee * Giuseppe Castagna, CNRS, LIENS, ENS Paris * Manuel Chakravarty, University of New South Wales * Karl Crary, Carnegie Mellon University * Sophia Drossopoulou, Imperial College London * Paul Feautrier, ENS Lyon * Carl A Gunter, University of Illinois * Rajiv Gupta, University of Arizona * Fritz Henglein, DIKU, University of Copenhagen * Trevor Jim, AT&T * Shriram Krishnamurthi, Brown University * Gary T Leavens, Iowa State * Robert O'Callahan, Novell * Peter O'Hearn, Queen Mary, University of London * Andreas Podelski, Max Planck Institute, Saarbrücken * Andrei Sabelfeld, Chalmers University * Kostis Sagonas, Uppsala University * Davide Sangiorgi, University of Bologna * Philip Wadler, University of Edinburgh * Stephanie Weirich, University of Pennsylvania * Hongwei Xi, Boston University Affiliated Events * Foundations of Object Oriented Languages (FOOL) * January 14, 2006 * Partial Evaluation and Semantics-Based Program Manipulation (PEPM) * January 9-10, 2006 * Practical Applications of Declarative Languages (PADL) * January 9-10, 2006 * Programming Language Technologies for XML (PLAN-X) * January 14, 2006 * Semantics, Program Analysis and Computing Environments for Memory Management (SPACE 2006) * January 14, 2006 * Verification, Model Checking and Abstract Interpretation (VMCAI) * January 8-10, 2006 POPL 2006 Preliminary Program Wednesday January 11, 2006 08:30 Invited talk Martin Odersky Ecole Polytechnique Fédérale de Lausanne 10:00 Staged Allocation: A Compositional Technique for Specifying and Implementing Procedure Calling Conventions Reuben Olinsky, Christian Lindig and Norman Ramsey Harvard University 10:25 A Hierarchical Model of Data Locality Chengliang Zhang, Yutao Zhong, Mitsunori Ogihara, Chen Ding University of Rochester 10:50 Simplifying Reductions Gautam Gupta and Sanjay Rajopadhye Colorado State University 11:40 Formal certification of a compiler back-end, or: programming a compiler with a proof assistant Xavier Leroy INRIA Rocquencourt 12:05 Engineering with Logic: HOL Specification and Symbolic-Evaluation Testing for TCP Implementations Steve Bishop, Matthew Fairbairn, Michael Norrish, Peter Sewell, Michael Smith and Keith Wansbrough University of Cambridge 14:00 Decidability and Proof Systems for Language-Based Noninterference Relations Mads Dam KTH 14:25 On Flow-Sensitive Security Types Sebastian Hunt and David Sands City University 14:50 A Logic for Information Flow Analysis of Pointer Programs Torben Amtoft, Sruthi Bandhakavi and Anindya Banerjee Kansas State University 15:45 Polymorphic Regular Tree Types and Patterns Jérôme Vouillon CNRS and Université Paris 7 16:10 Verifying Properties of Well-Founded Linked Lists Shuvendu K. Lahiri and Shaz Qadeer Microsoft Research 16:35 Environmental Analysis via Delta-CFA Matthew Might and Olin Shivers Georgia Institute of Technology 17:25 Small Bisimulations for Reasoning About Higher-Order Imperative Programs Vasileios Koutavas and Mitchell Wand Northeastern University 17:50 A Fixpoint Calculus for Local and Global Program Flows Rajeev Alur, Swarat Chaudhuri, and P. Madhusudan University of Pennsylvania Thursday January 12, 2006 08:30 Invited talk Tim Sweeney Epic Games Inc 10:00 Adventures in Time and Space James S. Royer Syracuse University 10:25 N-Synchronous Kahn Networks Albert Cohen, Christine Eisenbeis, Mard Duranton, Claire Pagetti, Florence Plateau, and Marc Pouzet INRIA Futurs 10:50 Compiler-Directed Channel Allocation for Saving Power in On-Chip Networks Guangyu Chen, Feihui Li, and Mahmut Kandemir Pennsylvania State University 11:40 Fast and Loose Reasoning is Morally Correct Nils Anders Danielsson, Jeremy Gibbons, John Hughes, and Patrik Jansson Chalmers University of Technology 12:05 Modular Set-Based Analysis from Contracts Philippe Meunier, Robert Bruce Findler, and Matthias Felleisen Northeastern University 14:00 Stratified type inference for generalized algebraic data types François Pottier and Yann Régis-Gianas INRIA 14:25 Hybrid Type Checking Cormac Flanagan UCSC 14:50 A Polymorphic Modal Type System for Lisp-like Multi-Staged Languages Ik-Soon Kim, Kwangkeun Yi and Cristiano Calcagno Seoul National University Friday January 13, 2006 08:30 Invited talk James McKinna St Andrews University 10:00 A Virtual Class Calculus Erik Ernst, Klaus Ostermann and William R. Cook University of Aarhus 10:25 Interruptible Iterators Jed Liu, Aaron Kimball and Andrew C. Myers Cornell University 10:50 Specifying C++ concepts Gabriel Dos Reis Bjarne Stroustrup Texas A&M University 11:40 Frame rules from answer types for code pointers Hayo Thielecke University of Birmingham 12:05 Certified Assembly Programming with Embedded Code Pointers Zhaozhong Ni and Zhong Shao Yale University 14:00 Associating Synchronization Constraints with Data in an Object-Oriented Language Mandana Vaziri, Frank Tip and Julian Dolby IBM Research 14:25 Autolocker: Synchronization Inference for Atomic Sections Bill McCloskey, Feng Zhou, David Gay and Eric Brewer UC Berkeley 14:50 Protecting Representation with Effect Encapsulation Yi Lu and John Potter UNSW 15:45 A Verifiable SSA Program Representation for Aggressive Compiler Optimization Vijay S Menon, Neal Glew, Brian R Murphy, Andrew McCreight, Tatiana Shpeisman, Ali-Reza Adl-Tabatabai and Leaf Petersen Intel Corporation 16:10 The Essence of Command Injection Attacks in Web Applications Zhendong Su and Gary Wassermann University of California, Davis 16:35 Harmless Advice Daniel Dantas and David Walker Princeton University 17:00 The Next 700 Data Description Languages Kathleen Fisher, Yitzhak Mandelbaum and David Walker AT&T Research and Princeton University

1 0

CfP: Applied Semantics, Special Issue of J of TCS
by Hans-Wolfgang Loidl 03 Nov '05

03 Nov '05

[ -- apologies for multiple copies of this CfP -- HWL ] CALL FOR PAPERS Special Issue on APPLIED SEMANTICS of the Journal of Theoretical Computer Science http://lionel.tcs.ifi.lmu.de/APPSEM05/journal_call.php We invite the submission of full papers on the topic of Applied Semantics, as described below, for publication in a special issue of the Journal of Theoretical Computer Science (TCS). Papers should be revised versions of those papers submitted to and presented at the APPSEM05 Workshop, Frauenchiemsee, Germany, September 12-15. However, we will consider submissions of papers not presented there, provided they fall into the scope of the call and clearly work out a novel contribution to the field that wasn't mature enough to be presented at the aforementioned workshop. Programming languages are the basic tools with which all applications of computers are built. It is important, therefore, that they should be well designed and well implemented. Achieving these goals requires both a good theoretical understanding of programming language designs, and practical skills in the development of high quality compilers. This special issue will cover all these areas and will focus on the formal basis for programming languages. The general areas covered by this special issue are as follows: 1. Program structuring: object-oriented programming, modules, 2. Proof assistants, functional programming, and dependent types, 3. Program analysis, generation, and configuration, 4. Specification and verification methods, 5. Types and type inference in programming, 6. Games, sequentiality, and abstract machines, 7. Semantic methods for distributed computing, 8. Resource models and web data, 9. Continuous phenomena in Computer Science. 10. Industrial applications. This list is non-exclusive, but contributions that do not clearly fall into one of these topics should carefully work out their relationship. We particularly invite industrial contributions covering the areas above. This could mean development of a novel language, a novel compiler, program analysis tools, or indeed, just a semantic model for a new kind of application. Again, this list is not exclusive and we welcome papers on any kind of industrial work which is informed by the science of programming languages, clearly states the problem being solved and elaborates on the main techniques of the above research areas being used to solve it. Programme committee: . Gavin Bierman, Microsoft Research . Olivier Danvy, University of Aarhus . Peter Dybjer, Chalmers University of Technology . Martin Hofmann, Ludwig-Maximilians-Universität München (Chair) . Neil Jones, University of Copenhagen . Hans Wolfgang Loidl, Ludwig-Maximilians-Universität München . Peter O'Hearn, Queen Mary College, University of London . Uday Reddy, University of Birmingham . Didier Remy, INRIA Rocquencourt . Ian Stark, University of Edinburgh . Thomas Streicher, Technische Universität Darmstadt . Peter Thiemann, Universität Freiburg Format of submission (see links below): Papers should be formatted according to Elsevier's elsart document style, used for articles in the Journal of Theoretical Computer Science. Submission should be electronically in .pdf format via the APPSEM Workshop page. Papers should have 20-25 pages, including appendices. Papers exceeding the upper bound may be rejected without refereeing. Important dates: . Paper submission: 8.1.2006 . Notification: 27.2.2006 . Camera-ready copy: 27.3.2006 Links: . APPSEM05 page and paper submissions: http://lionel.tcs.ifi.lmu.de/APPSEM05/ . TCS page: http://www.elsevier.com/wps/find/journaldescription.cws_home/505625/descrip… . Document style (elsart.cls): http://authors.elsevier.com/latex

1 0

RE: [Haskell] specification of sum
by Simon Marlow 03 Nov '05

03 Nov '05

On 02 November 2005 17:06, Scherrer, Chad wrote: >> Surely not... sum is defined by Haskell 98 as: >> >> sum = foldl (+) 0 >> >> and this is exactly what GHC provides. Furthermore we have >> specialised strict versions for Int and Integer. >> > > I'd been using ghci for testing along the way and getting terrible > results; does the specialization only apply to ghc per se? Yes, you need 'ghc -O' to get the optimised versions. The performance characteristics of unoptimised (including interpreted) code are often quite different. You can load the optimised module into GHCi, of course. Cheers, Simon

1 0

RE: [Haskell] specification of sum
by Simon Marlow 03 Nov '05

03 Nov '05

On 02 November 2005 00:20, Lennart Augustsson wrote: > Furthermore, ghc has a WRONG definition of sum. Surely not... sum is defined by Haskell 98 as: sum = foldl (+) 0 and this is exactly what GHC provides. Furthermore we have specialised strict versions for Int and Integer. Also, we shouldn't be turning overloaded functions into class methods purely for the purposes of providing optimised versions; that's what the SPECIALISE pragma is for. Cheers, Simon

3 2

The next langauage definition version will be ``Haskell 1.6''
by kahl＠cas.mcmaster.ca 03 Nov '05

03 Nov '05

Hi all, somebody wrote something which reminds me: ******************************************************************** * * * The ``next stable version'' of the Haskell language definition * * should be called ``Haskell 1.6''. * * * ******************************************************************** This follows the numbering scheme used before the current stable version. Some will still remember that during the discussion for the name of that version, a ballot was put out, and ``somehow'' the logical name ``Haskell 1.5'' was missing from that ballot --- it still received the second-most votes after ``Haskell 98'': as a free-form fill-in choice! But ``somehow'' nobody drew the consequence to do a corrected ballot... Add to that, that ``Haskell 98'' did of course not come out at a point of time that had any obvious relation with the number 98. Choosing ``Haskell 2006'' would therefore be equally unwise. And choosing something like ``Haskell 06'' would send a message that is completely wrong for a language that actually provides arbitrary-precision integers as its default integer number type. (It would also make version comparison even harder...) I therefore encourage everybody to refer to the current stable version as ``Haskell 1.5'', and stick with ``Haskell 1.6'' as the name for the next stable version. Wolfram

2 1

pattern matching on record fields and position
by David Roundy 03 Nov '05

03 Nov '05

Hello fellow haskellers, I have a couple of related (almost conjugate) proposals/questions. Basically, I've been thinking about how to make code more robust with respect to changes in the data types. Pattern matching based on positions is very fragile (I don't think this is a surprise to anyone). When you add a new field to a data type, you have to modify every bit of code that uses positional pattern matching, such as lengthPS (PS _ _ l) = l I'd like to be able export a data type with constructors in such a way that positional pattern matching isn't possible--but field-based pattern matching *is* possible. One could just use a coding policy, but I like the compiler enforcing things like this for me. Perhaps there's already a trick to do this? In particular, this would be relevant if I had the following data type: data FPS = PS { fp :: ForeignPtr Word8, my_start :: Int, my_length :: Int } I would like to be able to export this data constructor (in actual FastPackedString, the constructor isn't exported at all--and shouldn't be--but I'm taking this as a simple hypothetical example). I would like users (who import this module) to be able to write case fps of { PS { my_start = s } -> print s } but not to write case fps of { PS _ s _ -> print s } If I could enforce this, then I could change the definition of FPS to data FPS = PS { fp :: ForeignPtr Word8, my_start :: Int, my_length :: Int, extra_argument :: String } or data FPS = PS { fp :: ForeignPtr Word8, my_length :: Int, my_start :: Int } and have a guarantee that no code that imports the module will be broken. In the first example, all positional-matching code would fail to compile. The second is even more insidious, since code would continue to compile, but would be wrong! The second feature I'd like (and even better if it's something that already exists, although I've been told that it isn't) would be to be able to have record field names that are exported so as to not allow them to be used as accessor functions if those functions might lead to failure. For example: data Foo = AB { a :: String, b :: Int } | B { b :: Int } I would like "a" to be useable for pattern matching, but not as the function "a :: Foo -> String", which is dangerous, in that it really ought (in my opinion) to have the type Foo -> Maybe String. Actually, a compiler warning when using dangerous functions of this sort (as we can get when we use non-comprehensive pattern-matching) would satisfy me, although I'd really prefer to be able to have these accessor functions not be generated, or at least have an option to not export them. As you can probably tell, I've been thinking about how one can export constructors and yet still maintain flexibility in the implementation of data structures. Pattern matching is very nice, and often one wouldn't want to give it up, but it seems to completely tie down the implementation of data type, which is annoying, and seems to be a tradeoff that we could avoid by a combination of using field descriptors for pattern matching constructors. The catch being that for data types with multiple constructors, field descriptors always introduce "unsafe" functions that I'd really prefer didn't exist. -- David Roundy http://www.darcs.net

3 2

RE: [Haskell] specification of sum
by Scherrer, Chad 02 Nov '05

02 Nov '05

> Surely not... sum is defined by Haskell 98 as: > > sum = foldl (+) 0 > > and this is exactly what GHC provides. Furthermore we have > specialised strict versions for Int and Integer. > I'd been using ghci for testing along the way and getting terrible results; does the specialization only apply to ghc per se? > > Cheers, > Simon > Also, Cale, I was thinking about your comment about formal power series, and I don't see that (+) should not be strict in this case. In particular, if they are represented as infinite lists, I agree that zipWith (+) works just fine, though it is strict but lazy. Here is the strictness: zipWith (+) undefined [1,2,3] == undefined zipWith (+) [1,2,3] undefined == undefined And here is the laziness: head $ zipWith (+) (1:undefined) (2:undefined) == 3 Or am I missing something? -Chad

2 1