March 2003 - Haskell - Haskell.org

Enum on Float/Double
by George Russell 23 Oct '03

23 Oct '03

The situation with Enum on Ratio is pretty bad but at least it's not hopeless, since rational numbers are at least exact. But for Float/Double it seems to be a total disaster area. Since it seems to be impossible to abolish Enum Float/Double altogether, would it at least be possible to make it rather more useful, by making succ x return the next representable float after x (or x if x is non-finite) and pred x the previous representable float. This would (a) be useful; (b) make mathematical sense; (c) is tricky to implement with the existing primitives. Before someone else points it out, this is of course unimplementable should someone in the future implement infinite-precision reals in Haskell, but as (barring a solution to the halting problem) Eq would be as well, that does not bother me. My preference would be for succ (+-0) to return the smallest positive real, since then you could define succ x to be the unique y with x < y and forall z . z < y => not (x < z), where such a y exists, and I'm not sure if the Haskell standard knows about signed zeros. Feri wrote > Everybody working with floats should know their quirks While in an ideal world, everyone who represented a mouse position or anything else as a float should have a PhD in numerical analysis, in practice they do not. Indeed I think the Haskell Library Report contains quite a few examples of floating point code which a numerical analyst would have written rather better. So I don't think it's good enough to treat every Float/Double operation as if it had an implicit "UNSAFE" flag indicating that the compiler was entitled to wierd behaviour only comprehensible to experts, as seems to be the case with floating enumerations now.

8 11

CFP for RULE 2003
by RULE'03 workshop 31 Mar '03

31 Mar '03

********************************************************** *** RULE 2003: RPD workshop *** *** JUNE, 9, 2003 *** *** Valencia, Spain *** *** *** *** http://www.dsic.upv.es/~rdp03/rule/ *** ********************************************************** IMPORTANT DATE: April 6th 2003 - Submission of full paper Scope: ------ The rule-based programming paradigm is characterized by the repeated, localized transformation of a shared data object such as a term, graph, proof, or constraint store. The transformations are described by rules which separate the description of the sub-object to be replaced (the pattern) from the calculation of the replacement. Optionally, rules can have further conditions that restrict their applicability. The transformations are controlled by explicit or implicit strategies. The basic concepts of rule-based programming appear throughout computer science, from theoretical foundations to practical implementations. Term rewriting is used in semantics in order to describe the meaning of programming languages, as well as in the implementation of program transformation systems. It is used implicitly or explicitly to perform computations, e.g., in Mathematica, OBJ, or ELAN, or to perform deductions, e.g., by using inference rules to describe or implement a logic, theorem prover or constraint solver. Extreme examples of rule-based programming include the mail system in Unix which uses rules in order to rewrite mail addresses to canonical forms, or the transition rules used in model checkers. Rule-based programming is currently experiencing a renewed period of growth with the emergence of new concepts and systems that allow a better understanding and better usability. On the theoretical side, after the in-depth study of rewriting concepts during the eighties, the nineties saw the emergence of the general concepts of rewriting logic and of the rewriting calculus. On the practical side, new languages such as ASM, ASF+SDF, BURG, Claire, ELAN, Maude, and Stratego, new systems such as LRR and commercial products such as Ilog Rules and Eclipse have shown that rules are a useful programming tool. The practical application of rule-based programming prompts research into the algorithmic complexity and optimization of rule-based programs as well as into the expressivity, semantics and implementation of rules-based languages. The purpose of this workshop is to bring together researchers from the various communities working on rule-based programming to foster fertilisation between theory and practice, as well as to favour the growth of this programming paradigm. We solicit original papers on all topics of rule-based programming, including but not restricted to * Languages for rule-based programming o Expressivity o Semantics o Implementation techniques * Applications of rule-based programming o Analysis of rule-based programs o Programming methods * Environments for rule-based programming o (Partial) Evaluation o Abstract machines for rewriting * Combination of rule-based programming with other paradigms * System descriptions Submission procedure and publication: ------------------------------------- Submission process will be open in April 2003. Papers (of at most 15 pages) should be submitted electronically as PostScript or PDF files to one of the program committee chairs: - Jean-Louis Giavitto (giavitto(a)lami.univ-evry.fr) or - Pierre-Etienne Moreau (Pierre-Etienne.Moreau(a)loria.fr) The message should also contain a text-only abstract and author information. Accepted papers will be published and available during the workshop. After revision, final copies of the accepted papers will be published in Electronic Notes in Theoretical Computer Science (ENTCS), Elsevier Science. In addition, a selection of best papers could be published in a special issue of Higher-Order and Symbolic Computation. Program committee co-chairs: ---------------------------- Jean-Louis Giavitto, Evry Val d'Essone University, France Pierre-Etienne Moreau, LORIA-INRIA Nancy, France Program Committee members: -------------------------- James Cordy, Queen's University at Kingston, Canada Olivier Danvy, BRICS, Denmark Steven Eker, SRI International, USA Thom Fruehwirth, Ulm University, Germany Berthold Hoffmann, Bremen University, Germany Herbert Kuchen, Muenster University, Germany Oege de Moor, Oxford University Computing Laboratory, England Przemek Prusinkiewicz, Calgary University, Canada Patrick Viry, ILOG, France ----------------------------------------------------------------------- IMPORTANT DATES ----------------------------------------------------------------------- April 6th 2003 Submission of full paper May 5th 2003 Notification May 14th 2003 Final version due June 9th 2003 RULE 2003

1 0

Cfp: HLPP 2003 DEADLINE EXTENSION
by Frederic Loulergue 31 Mar '03

31 Mar '03

Please accept our apologies in case you receive this information from multiple sources. **** DEADLINE EXTENSION ** 18 April 2003 ***** ************************************************************************ HLPP 2003: Second International workshop on High-level parallel programming and applications Monday/Tuesday 16-17 June, 2003 Paris, France http://hlpp.free.fr ************************************************************************ Many applications of computing require performance levels attainable only on parallel architectures. Such systems are now readily available as their price/performance ratio continues to improve. The rapid development of affordable hardware for parallel computing makes the need to develop high-quality parallel software increasingly urgent. Sequential programming has long benefited from high-level programming techniques and tools that have made today's immense range of software economically viable. Two decades of research into high-level parallel programming has produced methods and tools that improve the price/performance ratio of parallel software, and broaden the range of target applications. GRIDs offer a tremendous computing power. Nevertheless, this power is far from being effectively exploited. In addition to technical problems related to portability and access, Grid computing needs new programming paradigms. Research on high level grid programming is particularly relevant. This workshop follows HLPP 2001 and is aimed at - computer science researchers, practitioners, graduate students - scientific computing researchers, practitioners, graduate students - high-performance application developers (e.g. in DBMS, data-mining, parallel model checking, virtual reality) Programme committee and organisers ---------------------------------- Rob Bisseling (Netherlands) Murray Cole (United Kingdom) Gaetan Hains (France) Herbert Kuchen (Germany) Frederic Loulergue (France) Quentin Miller (United Kingdom) Susanna Pelagatti (Italy) David Skillicorn (Canada) Contact : Frederic Loulergue (LACL, France) <loulergue(a)univ-paris12.fr> Papers and Publication ---------------------- We welcome submission of original, unpublished papers in English on topics including (but not limited to) - programming models and tools for GRID computing - algorithmic skeletons and parallel libraries - applications in all fields of high-performance computing - cost modelling (BSP, LogP, etc.) - experience with high-level tools and methods - object, functional, logic, constraint programming for parallel systems - parallel language design and implementation - parallel program design and optimisation Accepted papers should be presented at the workshop and will be published in special issues of Parallel Processing Letters, World Scientific Publishing (provided revisions suggested by the referees are made). Submission ---------- Papers should be sent to loulergue(a)univ-paris12.fr with subject "hlpp2003 submission" no later than Friday 18 April 2003. An early email with your intention to submit a paper would be greatly appreciated. Formatting instructions for paper submissions are available at http://hlpp.free.fr. Dates ----- Friday 18 April 2003 : deadline for submitted papers Friday 16 May 2003 : notification of acceptance/rejection Monday 2 June 2003 : deadline for draft proceedings versions of papers Sunday 15 June 2003 : pre-workshop social/cultural events in Paris Monday 16 June 2003 : Invited Speaker presentation of papers Tuesday 17 June 2003 : presentation of papers; workshop ends at noon ************************************************************************

1 0

Assistant Positions in Software Component Technology, ETH Zurich, Switzerland
by Peter Müller 29 Mar '03

29 Mar '03

Assistant Positions in Software Component Technology Department of Computer Science - ETH Zurich, Switzerland The new Software Component Technology group is recruiting two assistants (PhD students) to work in a young team on techniques and tools that enable the development of "trusted components", aiming at improving software quality and promoting reuse. The research of the Software Component Technology group focuses on techniques and tools for the development of correct object-oriented software components such as library classes. Together with the Chair of Software Engineering, our long-term objectives are to enable the development of "trusted components" and to establish a center for component certification. To achieve these goals, we concentrate on the following research areas: * Modular Specification and Verification Techniques to show that an object-oriented component behaves according to its specification in all contexts in which it might be reused. Our techniques are based on classical interface specification techniques and Hoare-logic, enhanced to specifically meet the requirements of component-based software development. * Language Design and Alias Control to improve encapsulation of components and complex pointer structures. We have developed a type system that can be used to statically describe properties of pointer structures, rule out common coding errors by static checking, and simplify formal reasoning. * Tool Support to make the application of formal techniques practical. We have implemented the Java Interactive Verification Environment, Jive, to support the development of correct software by applying static checking, interactive proof development, and semiautomatic proof strategies. Assistants are expected to participate in teaching, especially in the areas object-oriented programming, formal methods, semantics of programming languages, and project management. Among others, teaching activities include supporting courses and seminars as well as advising students doing their thesis work. Applicants must have a very good degree in Computing Science or in a related subject with a strong Computing Science component. They must also have documented practical experience in programming, preferably in object-oriented languages such as Java, C#, or Eiffel. Expertise in formal methods is a plus. Since assistants are expected to work towards a PhD, a strong interest in doing research as well as a good knowledge of English is required. Knowledge of German is a plus. An assistant position is a regular job with social benefits. Assistants at ETH receive an attractive salary and have access to excellent facilities in one of the world's top computer science departments. Zurich has just been voted #1 again in the world for quality of life (http://story.news.yahoo.com/news?tmpl=story2&u=/nm/20030303/hl_nm/cities_li vable_dc). As members of the new Software Component Technology group, the prospective assistants enjoy the benefits of a young team and the close cooperation with their advisor as well as the opportunities of collaborating with all members of the Chair of Software Engineering (Prof. Bertrand Meyer). For the preliminary web site of the Software Component Technology group consult http://www.inf.ethz.ch/~peter.mueller Questions on the positions and applications should be sent to Prof. Peter Mueller (peter.mueller(a)inf.ethz.ch) or to the postal address below. Applications should include a curriculum vitae, a brief description of research interests, and, if possible, letters of recommendation from teachers or employers. Postal Address: ETH Zurich Ruth Buerkli ETH Zentrum, RZ Building CH-8092 Zurich Switzerland

1 0

Debugging
by Per Larsson 28 Mar '03

28 Mar '03

I need to learn to use a debugging tool for haskell. There seems to be a whole bunch of them (Hood, Freja, Hat, Buddha, ...). Can anyone give me a (subjective) recommendation. Thanks Per

1 0

RE: Performance Timing
by Simon Marlow 27 Mar '03

27 Mar '03

> timer f a = do > t1 <- get current time > evaluate (f a) > t2 <- get current time > return (different in t2 and t1) > > where evaluate is from Control.Exception. could someone tell me how > evaluate compares to seq and deepSeq? The documentation explains the difference, but it's a bit cryptic. Informally: 'evaluate e' is an IO action that, when performed, forces e to weak-head normal form. It's a kind of seq that you can use in the IO monad. Cheers, Simon

1 0

Performance Timing
by Spencer Janssen 27 Mar '03

27 Mar '03

I've written two versions of a prime number sieve, and I'm trying to figure out how to performance test them. I've found functions to get the current date and time, and to subtract them, but when I put them in a do notation, I guess the laziness or something, makes the calculation happen first, then the two times are called, so I get almost 0 difference between the two. I guess I'm looking for something like this: timer :: (a -> b) -> a -> IO TimeDiff Spencer Janssen

2 1

Printing in Haskell
by Weix, Rachel Lynn 27 Mar '03

27 Mar '03

How do I print something in Haskell, i.e. if I want to print what a certain variable contains, etc.? (Synomous to cout> in C++, printf in C, System.out.println in Java, display in Scheme, etc.) Rachel

2 1

Fwd: Re: Haskell help!
by Marc Ziegert 26 Mar '03

26 Mar '03

---------- Weitergeleitete Nachricht ---------- Subject: Re: Haskell help! Date: Wed, 26 Mar 2003 23:57:42 +0100 From: Marc Ziegert <coeus(a)gmx.de> To: "Weix, Rachel Lynn" <weixrl(a)uwec.edu> i'm just programming the solution. imagine a matrix / a rectangle with a grid: the first word at the top side, the second at the right. each entry takes the best solutions of your sequencing problem using just a part of the words. in the top right there is the entry for the two empty words: (0,[ ("","") ]) the value is zero, the list has just one solution: ("","") below this entry: (-1,[ ("~","s") ]) at the bottom right: (-7,[ ("~~~~~~~","Masters") ]) all this was the rightmost column. the whole matrix is a list of columns - the head is the leftmost column. the head of one column is the entry at the bottom. the solution of the whole problem is at the bottom left - the head of the head of the matrix. - marc Am Mittwoch, 26. März 2003 23:32 schrieben Sie: > P.S. The example given is for the set of sequences/strings (The,Masters) > > -----Original Message----- > From: Weix, Rachel Lynn > Sent: Wed 3/26/2003 4:30 PM > To: coeus(a)gmx.de > Cc: haskell(a)haskell.org > Subject: RE: Haskell help! > > > Currently I'm having problems with type checking due to Haskell being a > strongly typed language. In order to return all optimal solutions, my > professor suggested I create a list of tuples if they all have the same > score, as indicated in my new maxSeq method (see attachment). However, > this means that the maxSeq method would return type [[(Char,Char)]]. Since > maxSeq and getSeq must return the same type, I end up changing all my > signatures and end up with lots of problems. In my caseX methods, I can't > append [(Char)] to [[(Char,Char)]], and it also messes up trying to get my > score of each tuple, etc. I've been trying to solve the problem in Scheme > first but even then I'm having problems, and Scheme is only loosely typed. > Any suggestions? The format should be something like the following > (partial example): > > [ [(-,M)] [(T,a)(h,s)(-,t)(e,e)(-,r)(-,s)] [(-,s)(h,t)(e,e)(-,r)(-,s)]]]. > > Once I get back my list, I need to pair everything up in order to return a > list of optimal solutions. Taking the previous example, it would be the > following when paired up correctly: > > [ [(-,M)(T,a)(h,s)(-,t)(e,e)(-,r)(-,s)], > [(-,M)(T,a)(-,s)(h,t)(e,e)(-,r)(-,s)] ] > > From there, I find which sequence has the maximum score. I then walk > through the list again, making a list of all the sequences that have that > score. These two steps seem fairly trivial, it's all the above stuff which > I'm struggling on. > > Rachel > > -----Original Message----- > From: Marc Ziegert [mailto:coeus@gmx.de] > Sent: Tue 3/25/2003 3:13 PM > To: Weix, Rachel Lynn > Cc: > Subject: Re: Haskell help! > > > > maxSeq had one mistake: || instead of && > > i will think about the problem itself, before rewriting all. > > this is the file a little bit more in haskell style. > > Am Dienstag, 25. März 2003 20:16 schrieben Sie: > > I found my two mistakes, plus I fixed the method my Professor said was > > incorrect. Now I just have to be able to find ALL optimal solutions, > > instead of just one. Hooray! > > > > Rachel -- Ein Unseliger, der nur kreist um sich selbst, im Leben wird er dem Ruhm nachsehen und doppelt sterbend untergehen; im gemeinen Staub, aus dem er entsprungen, unbeweint, ungeehrt und unbesungen. [Sir Walter Scott] ------------------------------------------------------- -- Ein Unseliger, der nur kreist um sich selbst, im Leben wird er dem Ruhm nachsehen und doppelt sterbend untergehen; im gemeinen Staub, aus dem er entsprungen, unbeweint, ungeehrt und unbesungen. [Sir Walter Scott]

1 0

RE: Haskell help!
by Weix, Rachel Lynn 26 Mar '03

26 Mar '03

P.S. The example given is for the set of sequences/strings (The,Masters) -----Original Message----- From: Weix, Rachel Lynn Sent: Wed 3/26/2003 4:30 PM To: coeus(a)gmx.de Cc: haskell(a)haskell.org Subject: RE: Haskell help! Currently I'm having problems with type checking due to Haskell being a strongly typed language. In order to return all optimal solutions, my professor suggested I create a list of tuples if they all have the same score, as indicated in my new maxSeq method (see attachment). However, this means that the maxSeq method would return type [[(Char,Char)]]. Since maxSeq and getSeq must return the same type, I end up changing all my signatures and end up with lots of problems. In my caseX methods, I can't append [(Char)] to [[(Char,Char)]], and it also messes up trying to get my score of each tuple, etc. I've been trying to solve the problem in Scheme first but even then I'm having problems, and Scheme is only loosely typed. Any suggestions? The format should be something like the following (partial example): [ [(-,M)] [(T,a)(h,s)(-,t)(e,e)(-,r)(-,s)] [(-,s)(h,t)(e,e)(-,r)(-,s)]]]. Once I get back my list, I need to pair everything up in order to return a list of optimal solutions. Taking the previous example, it would be the following when paired up correctly: [ [(-,M)(T,a)(h,s)(-,t)(e,e)(-,r)(-,s)], [(-,M)(T,a)(-,s)(h,t)(e,e)(-,r)(-,s)] ] From there, I find which sequence has the maximum score. I then walk through the list again, making a list of all the sequences that have that score. These two steps seem fairly trivial, it's all the above stuff which I'm struggling on. Rachel -----Original Message----- From: Marc Ziegert [mailto:coeus@gmx.de] Sent: Tue 3/25/2003 3:13 PM To: Weix, Rachel Lynn Cc: Subject: Re: Haskell help! maxSeq had one mistake: || instead of && i will think about the problem itself, before rewriting all. this is the file a little bit more in haskell style. Am Dienstag, 25. März 2003 20:16 schrieben Sie: > I found my two mistakes, plus I fixed the method my Professor said was > incorrect. Now I just have to be able to find ALL optimal solutions, > instead of just one. Hooray! > > Rachel

2 1