- Haskell - Haskell.org

ICFP: Accepted papers
by Kathleen Fisher 18 Jun '04

18 Jun '04

I am pleased to announce that the following papers have been accepted for ICFP 2004 (http://www.cs.indiana.edu/icfp04/) In addition, Paul Graham, John Launchbury, and Ulf Wiger have graciously agreed to give invited talks. The final program will be available from the web site mid-July. Kathleen Fisher *********************************************************** Slideshow: Functional Presentations Robert Bruce Findler and Matthew Flatt Functional Morphology Markus Forsberg and Aarne Ranta Types for Path Correctness for XML Queries Dario Colazzo, Giorgio Ghelli, Paolo Mangh, and Carlo Sartiani Regular Expression Patterns Niklas Broberg, Andreas Farre, and Josef Svenningsson, Multi-return function call Olin Shivers and David Fisher Implementing Functional Logic Languages Using Multiple Threads and Stores Andrew Tolmach, Sergio Antoy, and Marius Nita Generics for the masses Ralf Hinze Scrap more boilerplate: reflection, zips, and generalised casts Ralf Laemmel and Simon Peyton Jones Making a fast curry: Push/enter vs eval/apply for higher-order languages Simon Marlow and Simon Peyton Jones Improving Static Analysis via Partial Evaluation for Embedded Languages David Herman and Philippe Meunier Searching for Deadlocks while Debugging Concurrent Haskell Programs Jan Christiansen and Frank Huch A Nanopass Infrastructure for Compiler Education Dipanwita Sarkar, Oscar Waddell, and R. Kent Dybvig Monadic Regions Matthew Fluet and Greg Morrisett Translating Dependency into Parametricity Stephen Tse and Steve Zdancewic A Type-Theoretic Foundation of Continuations and Prompts Zena Ariola, Hugo Herbelin, and Amr Sabry, Relating Models of Backtracking Mitchell Wand and Dale Vaillancourt Types, potency, and impotency: Why nonlinearity and amnesia make a type system work Peter Møller Neergaard and Harry Mairson Numbering Matters: First Order Canonical Forms for Second-Order Recursive Types Nadji Gauthier and François Pottier Process Logic and Duality Kohei Honda Verification of Safety Properties for Concurrent Assembly Code Dachuan Yu and Zhong Shao A Sound (and Complete) Model for Contracts Matthias Blume and David McAllester ------------------------------------------------------------

1 0

Last CFP: CLIMA V - 5th International Workshop on Computational Logic in Multi-Agent Systems
by João Leite 18 Jun '04

18 Jun '04

========================================================================== LAST CALL FOR PAPERS CLIMA V Fifth International Workshop on Computational Logic in Multi-Agent Systems September 29 and 30, 2004, Lisbon, Portugal http://centria.di.fct.unl.pt/~jleite/climaV/index.htm Submission Deadline: June 25th (abstracts due June 22nd) Springer LNCS Proceedings Co-located with JELIA'04 =========================================================================== CALL FOR PAPERS Multi-agent systems are communities of problem-solving entities that can perceive and act upon their environments to achieve their individual goals as well as joint goals. The work on such systems integrates many technologies and concepts in artificial intelligence and other areas of computing. For this reason, over recent years, the agent paradigm gained popularity in many sub-fields of computer science. A full spectrum of multi-agent systems applications have been and are being developed; from search engines to educational aids to electronic commerce and trade, e-procurement, recommendation systems, simulation and routing, to cite only some. Although commonly implemented by means of imperative languages, mainly for reasons of efficiency, the agent concept has recently increased its influence in the research and development of computational logic based systems. Computational logic provides a well-defined, general, and rigorous framework for studying syntax, semantics and procedures, for attending implementations, environments, tools, and standards, and for linking together specification and verification of properties of computational systems. The purpose of this workshop is to discuss techniques, based on computational logic, for representing, programming and reasoning about multi-agent systems in a formal way. Following the workshop on Multi-Agent Systems in Logic Programming affiliated with ICLP'99, the first CLIMA workshop took place in London, UK, affiliated with CL'2000. The 2001 edition of CLIMA, took place in Paphos, Cyprus, affiliated with ICLP'01. CLIMA'02 took place in Copenhagen, Denmark, and was affiliated with ICLP'02 and part of FLOC'02. The fourth edition of the workshop, CLIMA IV, took place in Fort Lauderdale, USA, and was co-located with LPNMR-7 and SAIM'04. We solicit unpublished papers that address formal approaches to multi-agent systems. the approaches as well as being formal must make a significant contribution to the practice of multi-agent systems. relevant techniques include, but are not limited to, the following: * logical foundations of multi-agent systems * knowledge and belief representation and updates in multi-agent systems * agent and multi-agent hypothetical reasoning and learning * extensions of logic programming for multi-agent systems * nonmonotonic reasoning in multi-agent systems * theory and practice of argumentation for agent reasoning and interaction * operational semantics and execution agent models * model checking algorithms, tools, and applications for multi-agent logics * semantics of interaction and agent communication languages * distributed constraint satisfaction in multi-agent systems * temporal reasoning for multi-agent systems * modal logic approaches to multi-agent systems * logic based programming languages for multi-agent systems * distributed theorem proving for multi-agent systems * logic based implementations of multi-agent systems * decision theory for multi-agent systems * specification and verification of formal properties of agent systems SUBMISSION INSTRUCTIONS We welcome and encourage the submission of high quality, original papers, which are not simultaneously submitted for publication elsewhere. Please refer to the workshop web pages for further instructions concerning the submission procedures. IMPORTANT DATES * Submission of Abstracts: June 22nd, 2004 * Submission of Papers: June 25th, 2004 * Notification of Acceptance: July 30th, 2004 * Final version due: September 6th, 2004 * CLIMA IV: September 29-30th, 2004 PROCEEDINGS The post-proceedings of CLIMA will be published by Springer-Verlag as a volume of the Lecture Notes on Artificial Intelligence series. PROGRAM COMMITTEE * José Alferes, New University of Lisbon, Portugal * Gerd Brewka, University of Leipzig, Germany * Jürgen Dix, Technical University of Clausthal, Germany * Klaus Fischer, DFKI, Germany * Michael Fisher, University of Liverpool, UK * James Harland, Royal Melbourne Institute of Technology, Australia * Katsumi Inoue, National Institute of Informatics, Japan * Sverker Janson, Swedish Institute of Computer Science, Sweden * João Leite, New University of Lisbon, Portugal * Yves Lespérance, York University, Canada * John Jules Ch. Meyer, University of Utrecht, The Netherlands * Leora Morgenstern, IBM, USA * Wojciech Penczek, Polish Academy of Sciences, Poland * Jeremy Pitt, Imperial College, UK * Enrico Pontelli, New Mexico State University, USA * Fariba Sadri, Imperial College, UK * Ken Satoh, National Institute of Informatics, Japan * Renate Schmidt, The University of Manchester, UK * Tran Cao Son, New Mexico State University, USA * Francesca Toni, Imperial College, UK * Paolo Torroni, University of Bologna, Italy * Wiebe Van Der Hoek, University of Liverpool, UK * Makoto Yokoo, Kyushu University, Japan * Cees Witteveen, Delft University of Technology, The Netherlands WORKSHOP ORGANIZERS: * João Leite, New University of Lisbon, Portugal (jleite(a)di.fct.unl.pt) * Paolo Torroni, University of Bologna, Italy (ptorroni(a)deis.unibo.it) INQUIRIES: Please send program suggestions and inquires to either of the organizers.

1 0

Monadic Loops
by Vivian McPhail 17 Jun '04

17 Jun '04

Hi, I've implemented a Neural Net simulator which needs to repeat a training loop many times. For this I used a while function: while test body = do (cond,res) <- body if (test cond) then do rs <- while test body return (res:rs) else return [res] However, when I run the program, the interpreter falls over after a few thousand iterations, running out of space. I think that this is because the Monadic implementation of the while loop actually nests functions of type (a -> M b) and there is a maximum ?stack size. Is there a better way to implement (possibly infinite) loops in Haskell?

2 1

ICTAC 2004: Extended Deadline (5 July)
by Bernhard K. Aichernig 17 Jun '04

17 Jun '04

***** Extended Deadline (5 July) ***** ICTAC 2004 FIRST INTERNATIONAL COLLOQUIUM ON THEORETICAL ASPECTS OF COMPUTING Guiyang, China 20 - 24 September 2004 http://www.iist.unu.edu/ICTAC2004 IMPORTANT DATES Submission deadline of papers: 5 July (extended!) Notification of acceptance: 9 August Final version due: 30 August Submission deadline of tutorial proposal 21 June Notification of tutorial acceptance 12 July Tutorials 20 - 21 September Workshop 22 - 24 September AIMS AND OBJECTIVES The International Institute for Software Technology of the United Nations University (UNU-IIST) decides to found an International Colloquium on Theoretical Aspects of Computing (ICTAC). The aim of the colloquium is to bring together practitioners and researchers from academia, industry and government to present research results, and exchange experience, ideas, and solutions for their problems in theoretical aspects of computing. We believe that this will help the developing countries to strengthen their research, teaching and development in computer science and engineering, to improve the links between developing countries and developed countries, and to establish collaboration in research and education. The technical program lasts five days including two days for tutorials and three days for a workshop. We plan to organize such a colloquium every 18 months jointly with a UNU-IIST training school in a developing country, and each time there will be a theme and a focus. The school participants will also attend the technical program of the colloquium. A small registration fee will be charged to cover meals tutorial handouts and proceedings only. There will be also a limited amount of grant that participants, tutorial and workshop speakers from developing countries can apply. Application should be submitted together with their tutorial proposals or papers to the workshop. The first ICTAC will be jointly organized by the Guizhou Academy of Sciences and UNU-IIST during 20-24 September 2004. SCOPE AND TOPICS ICTAC 2004 calls for tutorials in the areas of theoretical aspects of computing including automata, languages, software engineering and formal methods and solicits research papers for the workshop related to, but not limited to, the following principal topics: * automata theory and formal languages * principle and semantics of programming languages * logics and their applications * software architectures and their description languages * software specification, refinement and verification * models of object and component system * coordination and feature interaction * integration of formal and engineering methods * service-oriented development * document-driven development * models of concurrency, security and mobility * theory of parallel, distributed and internet-based (Grid) computing * real-time and embedded systems * type and category theory in computer science SUBMISSIONS OF TUTORIAL PROPOSALS Proposals should be approximately five pages and must include the following information: * contents including abstract and syllabus/contents * duration of the tutorial (2 hours - 6 hours) * intended audience including prerequisites * biography of presenter * any special requirements (e.g., software/hardware for tool demo, software/hardware requirements for participants) Please send proposals (in postscript or PDF format) via email directly to the Program Chair Zhiming Liu at lzm(a)iist.unu.edu. SUBMISSIONS TO THE WORKSHOP Submissions to the workshop must not have been published or be concurrently considered for publication elsewhere. All submissions will be judged on the basis of originality, contribution to the field, technical and presentation quality, and relevance to the workshop. The ICTAC 2004 Program Committee selects original technical papers for publication in the proceedings of the workshop and envisages published the proceedings after the workshop by Springer in its Lecturer Notes in Computer Science series. Papers should be written in English and not exceed 15 pages in LNCS format: see. http://www.springer.de/comp/lncs/authors.html for details. Further information and instructions about submissions can be found on the colloquium website http://www.iist.unu.edu/ICTAC2004. Authors are strongly encouraged to use this website to submit their papers in electronic form. INVITED SPEAKERS Jose Luiz Fiadeiro (University of Leicester, UK) Jifeng He (UNU-IIST, Macao) K. Rustan M. Leino (Microsoft Research, WA, USA) Huimin Lin (Institute of Software, CAS, Beijing, China) Program Committee Chairs Keijiro Araki (Kyushu University, Japan) Zhiming Liu (UNU/IIST, Macao SAR China) Publicity Chairs Bernhard Aichernig (UNU/IIST, Macao) Dan Li (Academy of Sciences, Guizhou, China) Finance Chair Danning Li (Academy of Sciences, Guizhou, China) Organization Chair Danning Li (Academy of Sciences, Guizhou, China) Advisory Committee Dines Bjoerner (Denmark), Manfred Broy (Germany), Jose Luiz Fiadeiro (University of Leicester, UK), Jifeng He (UNU-IIST), Mathai Joseph (India), Shaoying Liu (Japan), Zhiming Liu (UNU-IIST), Jim Woodcock (UK) Program Committee Luis S. Barbosa (University of Minho, Portugal) Gabriel Baum (National University of La Plata, Argentina) Hubert Baumeister (LMU, Munich, Germany) Jonathan Bowen (London South Bank University, UK) Cristian S. Calude (University of Auckland, New Zealand) Ana Cavalcanti (University of Kent, UK) Wei Ngan Chin (NUS, Singapore) Jim Davies (Oxford University, UK) Henning Dierks (University of Oldenburg, Germany) Jin Song Dong (National University, Singapore) Wan Fokkink (CWI, the Netherlands) Michael R. Hansen (DTU, Lyngby, Denmark) James Harland (RMIT University, Melbourne, Australia) Jozef Hooman (Embedded Systems Institute, Eindhoven, the Netherlands) Guoxing Huang (ECNU, Shanghai, China) Purush Iyer (North Carolina State University, USA) Ryszard Janicki (McMaster University, Ontario, Canada,) Michael Johnson( Macquarie University, Sydney, Australia) Fabrice Kordon (University of Paris VI, France) Maciej Koutny (University of Newcastle upon Tyne, UK) Kung-Kiu Lau (Manchester University, UK) Antonia Lopes (University of Lisbon, Portugal) Jian Lu (Nanjing University, China) Andrea Maggiolo-Schettini (University of Pisa, Italy) Huaikou Miao (Shanghai University, China) Paniti Netinant (Bangkok University, Thailand) Paritosh Pandya (TIFR, Mumbai, India) Zongyan Qiu (Peking University, Beijing, China) Anders P. Ravn (Aalborg University, Denmark) Gianna Reggio (University of Genova, Italy) Riadh Robbana (LIP2/EPT, Tunisia) Augusto Sampaio (Federal Univ of Pernambuco, Recife, Brazil) Bernhard Schatz (TU Munchen, Germany) Irek Ulidowski (University of Leicester, UK) Ji Wang (National Lab for Parallel and Distributed Processing, China) Wang Yi (Uppsala University, Swiden) Jian Zhang (Institute of Software, CAS, China) Mingyi Zhang (Academic of Sciences, Guizhou, China) Hongjun Zheng (Semantics Designs Inc, USA) -- Bernhard Aichernig, Research Fellow of UNU-IIST www.iist.unu.edu/~bka ---------------------------------------------------------------------- Go to China for SEFM 2004 www.iist.unu.edu/SEFM2004 and ICTAC 2004. www.iist.unu.edu/ICTAC2004 Plan to attend ASE 2004! www.ase-conference.org See you at FM 2005 www.csr.ncl.ac.uk/fm05

1 0

ICFP Poster Session
by Amr A Sabry 17 Jun '04

17 Jun '04

The 2004 ICFP Poster Session http://abstract.cs.washington.edu/~djg/icfp-poster.html Part of the 2004 International Conference on Functional Programming http://www.cs.indiana.edu/icfp04/ The 2004 International Conference on Functional Programming (ICFP) will include a poster session during the first day of the conference. The poster session aims to give students and professionals an opportunity to gain experience presenting technical material to the research community, and to get technical advice from leading researchers in the field. PARTICIPANT OBLIGATIONS: * Sign-up via the on-line form below by June 30, 2004. * Submit a one-page abstract summarizing the poster topic by July 15, 2004. * Register for ICFP 2004. (There is no separate poster registration beyond the on-line sign-up form.) * Prepare a poster and attend the session on September 19, 2004. In addition, participants are strongly encouraged to prepare a short article (roughly 2 or 3 pages) for peer feedback and to provide feedback for some other participants' articles. This process should improve the quality of the posters. Articles should be submitted by August 1, 2004. NUMBER OF PARTICIPANTS: * We hope to accomodate everyone wishing to participate, but may restrict participation (based on relevance and interest to the community) in the case of unmanageably high interest. * We may need to cancel the session if there is too little interest, roughly fewer than ten participants. * To ensure we know there is interest, please sign-up promptly. Somebody has to be first and there is no danger you will be the sole participant. POSTER PRESENTATIONS: In the poster session, each participant will be provided with a space for posting their diagrams and short descriptions of their research (approximately 3x6 feet, or 1x2 meters). Contact with your audience happens through casual conversation. Count on only a reasonable attention span when describing your work. Over five minutes is usually overdoing it. Prepare a list of questions that you would like help getting answered. Please feel free to direct any questions that you might have to: Dan Grossman, ICFP2004 Poster Session Chair http://www.cs.washington.edu/homes/djg

2 1

The two-class trick
by oleg＠pobox.com 16 Jun '04

16 Jun '04

The two-class trick helps us indirectly write desirable multi-parameter classes with functional dependencies or overlapping. The example below happens to have both. The example illustrates that an attempt to write desired instances directly runs into problems of bad overlapping or violations of functional dependencies. The trick lets us get around those unfortunately quite common problems. Many if not all problems with overlapping instances can be solved with the general approach described in the HList paper [HList]. The paper conjectures that the overlapping instances extension itself may be unnecessary after all. The HList paper: http://www.cwi.nl/~ralf/HList/ The two-class trick still seems worth explaining because it gives an example of turning an apparent drawback of the instance selection algorithm to our advantage. In Haskell, class instances are chosen based only on the syntactic shape of the type terms in question. Specifically, instance constraints, if any, do _not_ affect the instance selection. This fact is often considered one of the major stumbling blocks to using Haskell overloading for ``logical programming''. The instance selection algorithm is somewhat akin to the selection of the appropriate function declaration clause. We can influence the selection by adding a guard -- an arbitrary boolean expression -- to a function clause. Alas, we cannot similarly influence the selection of an instance by adding a constraint. If an instance has a constraint, the latter is checked _after_ the typechecker has selected and become committed to that instance. If that constraint turns out unsatisfiable, the whole typechecking fails. There is no backtracking: the typechecker does not attempt to choose another instance. This message is the complete code. Therefore, we need preliminaries > {-# OPTIONS -fglasgow-exts #-} > {-# OPTIONS -fallow-undecidable-instances #-} > {-# OPTIONS -fallow-overlapping-instances #-} > > module DelH where > > data HNil = HNil deriving Show > data HCons a b = HCons a b deriving Show A sample heterogenous list is as follows: > l1 = HCons True $ HCons 'a' $ HCons "ab" $ HCons 'z' $ HNil The HList paper defines infix operators that make building heterogenous lists far more pleasant. Please see the HList paper [HList] for much more explanations and many more operations on heterogenous lists. Our goal here is to write a function |hdel| that deletes the first occurrence of an element of a given type from a given heterogeneous list. For example, > test1 = hdel 'x' l1 will delete the first element of the type |Char| from the list |l1|: *DelH> l1 HCons True (HCons 'a' (HCons "ab" (HCons 'z' HNil))) *DelH> test1 HCons True (HCons "ab" (HCons 'z' HNil)) The given list must contain at least one element of the desired type. Otherwise, it is a type error. We can start by writing > class HDeleteFst e l l' | e l -> l' where > hdel:: e -> l -> l' > instance HDeleteFst e (HCons e l) l where > hdel _ (HCons _ l) = l At first, the code is quite straightforward: if we see the occurrence of the desired element type in the head of |HList|, we return the tail of the list. We are tempted to write the second case (when the desired element type is not in the head of the list) as follows *> instance HDeleteFst e l l' => *> HDeleteFst e (HCons e' l) (HCons e' l') where *> hdel e (HCons e' l) = HCons e' (hdel e l) Alas, that does not work. The most general unifier of the instances HDeleteFst e (HCons e l) l and HDeleteFst e (HCons e' l) (HCons e' l') is e' -> e, l -> (HCons e l') The unifier exists, therefore, the instances do overlap. However, there is no such substitution that, when applied to the second instance makes it identical to the first, nor vice versa. So, the instances are unifiable but not comparable -- and the compiler will complain. The trick is to introduce a helper class > class HDeleteFst' e l l' | e l -> l' where > hdel':: e -> l -> l' which is in all respect similar to the first class. Now, we add a relaying instance of |HDeleteFst|: > instance HDeleteFst' e l l' => HDeleteFst e l l' where > hdel = hdel' As we can see, the two instances of our class, |HDeleteFst e (HCons e l1) l1| and |HDeleteFst e l l'| still overlap. Now, the former is strictly more specialized than the latter, because there exists a substitution |l -> (HCons e l1), l -> l1|, which, when applied to the general instance makes it identical to the former instance. GHC no longer complains because now the overlapping instances are ordered and so the compiler can choose the right one. We still need to add an instance for the new class |HDeleteFst'| > instance HDeleteFst e l l' => > HDeleteFst' e (HCons e' l) (HCons e' l') where > hdel' e (HCons e' l) = HCons e' (hdel e l) Modulo the substitution |HDeleteFst'| for |HDeleteFst| and |hdel'| for |hdel|, this is precisely the instance we wanted -- but could not write before. In writing the relaying instance of |HDeleteFst| we specifically relied on the fact that instances are chosen only on the syntactic shape of the type terms in question. The constraints (in our case, |HDeleteFst' e l l'|) are checked only after the selection is complete.

1 0

RE: [Haskell] IO, exceptions and error handling
by Tim Docker 15 Jun '04

15 Jun '04

Keith Wansbrough wrote: > s/fail/error/ > s/return// > > Then you can easily write > > > I can't (easily) write > > > > text c = sqr x + sqr (x+1) > > You just can't *catch* this outside the IO monad. Of course... that was my second alternative error strategy. I'm interest in how/when people decide when to throw exceptions versus when to thread errors using monads, given that changing code from one to the other could be quite a big deal. Tim

2 1

IO, exceptions and error handling
by Graham Klyne 15 Jun '04

15 Jun '04

I'm finding that a recurring theme in my work with Haskell libraries (and in particular the XML libraries) is the awkwardness of handling errors outside the IO monad. While it's often very easy to write some code that performs some function, assuming that the inputs are valid, as soon as code is required to deal with incorrect input, life gets more complicated. The choice seems to be that the functions have to be re-modelled to return a value that incorporates a possible error condition, or any such error condition results in a failure of the calling program, removing the the calling program's option to effect a recovery strategy. The exception handling system made available in the IO monad is one way out of this awkwardness, but it's only available when the recovery code is coded to run in the I/O monad (or by using unsafePerformIO). I find this is problematic when I'm trying to write a general purpose library that uses some other general-purpose library that can raise errors. I can't see any fundamental reason why exception handling has to occur in the IO monad. E.g. I'm not aware that something like this would break the Haskell type assurances: class (Eq e, Show e, Show v) => Exception e v where makeExcept :: v -> e catchExcept :: a -> (e->a) -> a throw :: e -> a instance Exception IOError String where makeExcept = userError catchExcept = catch throw e = error (show e) -- for Haskell implementations that allow errors -- to be caught in the IO monad I think a limited implementation may be possible using unsafePerformIO: data MyException = MyException String showEx (MyException s) = s instance Exception MyException String where makeExcept = MyException catchExcept a h = unsafePerformIO $ catch (return a) throw e = fail (showEx e) ... Another approach that occurs to me is to introduce an error Monad along the lines of that described by Philip Wadler as "E" in his "Essence of functional programming" paper [1]. (Or just use Either as an error monad?, which is part of what I've been doing with my XML work.) The disadvantages I see here are: (a) it requires existing code to be modified to return the error monad value. (b) it imposes a strict sequencing on the order of computation, which as far as I can see is not necessary to achieve the required error handling. For example, a computation that returns a result that is not actually used in a subsequent computation would still cause an exception; e.g. do { b <- f1 -- False ; c <- f2 -- raises exception ; d <- f3 -- value required ; return (if b then c else d) } (I know this could be coded differently to avoid the claimed problem, but to my mind it still illustrates unnecessary complexity compared with: if f1 then f2 else f3 In effect, it requires the programmer to figure out the lazy evaluation sequences instead of letting the Haskell system do it.) ... I'll note that I have reservations about using exception handling in imperative languages (because it disrupts the normal guarantees of execution flow), but I can't see any corresponding disadvatages to using exceptions in a purely functional language environment. Are there any plans or thoughts for introducing more widely usable exception handling in "Haskell 2"? #g -- [1] http://homepages.inf.ed.ac.uk/wadler/papers/essence/essence.ps and others, linked from: http://homepages.inf.ed.ac.uk/wadler/topics/monads.html (cf. section 2.3) ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

6 6

RE: [Haskell] IO, exceptions and error handling
by Tim Docker 14 Jun '04

14 Jun '04

Philippa Cowderoy wrote: > The ability to fail doesn't need the do notation, just use of > return for success - similar for propagating failure. I'm not sure I understand. Do you mean writing functions like: sqr x | x < 0 = fail "less than zero" | otherwise = return (sqrt x) If so, I don't see how I can use this without either do or >>=: test x = do v1 <- sqr x v2 <- sqr (x+1) return (v1+v2) I can't (easily) write text c = sqr x + sqr (x+1) which was what I was getting at. Tim

3 2

[Haskell] Programming language shootout (completing the Haskell entry)
by Sean E. Russell 14 Jun '04

14 Jun '04

Hiya, I know it is silly, but I'm interested in helping to complete the Haskell entry in the Programming Language Shootout page[1] (http://www.bagley.org/~doug/shootout/craps.shtml) The Haskell entry is missing 5 (out of 13) entries, and since no points are "scored" for missing entries, this skews Haskell's rank downwards. Since I'm not the worlds Best Haskell Programmer -- and I'm certainly not adept at optimizing, and since I'd like to provide the fastest Haskell code that I can, I thought I'd run it through my code through this list and see if anybody would like to suggest improvements. The implementations for this particular test must be written in the "same way"; this is defined to be that the submissions "use the same logic and data structures", the goal being to "try to measure languages doing the same operations, as closely as possible." The "description" of the test is: "In this test, we create 10000 hash entries, then add them into a new hash N times. " The correct output for this code where N=10 must be: 1 9999 10 99990 I chose to use (lookup) and associative arrays. I create a *bunch* of hashes, rather than just two that I re-use because, honestly, I'm such a novice I don't know how to do it otherwise. Anyway, as I said, any suggestions for optimization are appreciated. This is just for fun. ===== BEGIN hash2.hs module Main where import System (getArgs) import Numeric (readDec) import Maybe main = do argv <- getArgs let h1 = hash1 9999 [] h2 = hash2 (fst $ head $ readDec $ argv!!0) h1 [] print h1 h2 where hash1 0 x = x hash1 n xs = hash1 (n-1) ((mkentry n):xs) mkentry y = ( "foo_"++(show y), y ) hash2 0 _ x2 = x2 hash2 n x1 x2 = hash2 (n-1) x1 [ (k1, v1+(get k1 x2)) | (k1, v1) <- x1 ] print x1 x2 = putStrLn ( (show $ get "foo_1" x1)++" "++ (show $ get "foo_9999" x1)++" "++ (show $ get "foo_1" x2)++" "++ (show $ get "foo_9999" x2) ) get :: String -> [(String, Int)] -> Int get key hash = fromMaybe 0 $ lookup key hash ===== END hash2.hs [1] The page is entirely tounge-in-cheek, but I find it interesting, nonetheless. -- ### SER ### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido ### http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737 ### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg

9 12