October 2003 - Haskell

CfP: SNPD'03 Workshop on High-Level Approaches to Parallel and Distributed Computing
by Clemens Grelck 08 Jul '04

08 Jul '04

Please apologize in case you receive multiple copies of this information. ========================================================================== CALL FOR PAPERS Workshop on High-Level Approaches to Parallel and Distributed Computing held in the context of the Fourth ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD'03) October 16th - 18th, 2003 Luebeck, Germany http://www.isp.uni-luebeck.de/snpd03/Workshop/ws02/index.htm ========================================================================== Scope and Topics: ================== Today parallel and distributed computing systems are readily available and provide a continuously improving price/performance ratio. However, this technological breakthrough in hardware is not accompanied by similar progress in software technology. Parallel and distributed programming is still dominated by low-level techniques such as explicit message passing. This low level of abstraction makes programming these systems exceedingly difficult, time-consuming, and error-prone. Hence, parallel and distributed computing requires new programming models which liberate programmers from low-level concerns and increase programming productivity while maintaining reasonable trade-offs between level of abstraction and runtime performance. Topics of interest include, but are not limited to - methodologies for high-level parallel programming, - parallel programming languages, - high-level libraries for parallel computing, - compilers and runtime systems for parallel computing, - implementation aspects of high-level parallel programming environments, - compiler-based optimization and parallelization, - experience with high-level parallel programming environments, - support for debugging and performance analysis, - concurrent array programming, - programming concepts for the grid. This workshop provides a forum for researchers and practitioners interested in the design, implementation, and evaluation of high-level parallel programming concepts. It aims at creating some focus within the otherwise broad spectrum of the SNPD'03 conference. Workshop Chair and Organizer: ============================== Clemens Grelck University of Luebeck Institute of Software Technology and Programming Languages Seelandstr. 1A 23569 Luebeck, Germany E-Mail: grelck(a)isp.uni-luebeck.de Papers and Publication: ======================== Original, unpublished papers in English not exceeding 8 pages in ACIS double column format are solicited. For detailed formatting instructions see the SNPD'03 conference web site at http://www.isp.uni-luebeck.de/snpd03/index.htm Please send your papers as PDF documents by electronic mail directly to the workshop chair: grelck(a)isp.uni-luebeck.de Please indicate your paper submission by the subject SNPD03 WORKSHOP SUBMISSION Accepted papers will be published in the conference proceedings with ISBN. A selection of excellent papers presented at the conference including its workshops will be published in a special issue of the International Journal of Computer and Information Science. Important Deadlines: ===================== Full paper submission due: August, 30th Notification of acceptance: September, 10th Camera-ready papers due: September, 24th

1 3

RE: How overload operator in Haskell?
by Hal Daume 06 Nov '03

06 Nov '03

What you want to do is make your Vector an instance of the Num(eric) type class. For instance: instance Num Vector where (+) v1 v2 = zipWith (+) v1 v2 (-) v1 v2 = zipWith (-) v1 v2 negate v1 = map negate v1 abs v1 = map abs v1 (*) v1 v2 = ... fromInteger i = ... signum v1 = ... I've left the last three blank because it's unclear what should go there. Since (*) has type Vector->Vector->Vector (in this instance), you can't use dot product or something like that. signum :: Vector->Vector could be written and just return [-1], [0] or [1], I suppose. fromInteger :: Integer->Vector is a little harder. Perhaps just 'fromInteger i = [fromInteger i]' would be acceptable. Or you could leave these undefined. -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -----Original Message----- > From: haskell-admin(a)haskell.org > [mailto:haskell-admin@haskell.org] On Behalf Of Liu Junfeng > Sent: Wednesday, July 09, 2003 7:25 AM > To: haskell(a)haskell.org > Subject: How overload operator in Haskell? > > > I've learned haskell months, but I still can't understand the > type system very well. > I can only write: > ----------------------------------- > type Vector = [Double] > vadd,vsub :: Vector->Vector->Vector > v1 `vadd` v2 = zipWith (+) v1 v2 > v1 `vsub` v2 = zipWith (-) v1 v2 > svmul :: Double->Vector->Vector > s `svmul` v = map (s*) v > ------------------------------------ > Tough it works, it is not convenient to use. How to create a > Vector type and overload > mathematical operators? > Thanks for your help. > > Liu Junfeng > liujf(a)softhome.net > > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

12 14

Re: GHC and Kinds
by Steffen Mazanek 30 Oct '03

30 Oct '03

Hello, > It means that Kinds are represented by Types. > > Admittedly, Kinds only use a small fragment of what Types can represent, > namely Arrow, and type constructor applications. So * is represented by > a TyConApp with a TyCon that is called typeCon. > > The really annoying thing about Kinds is that there's occasionally a bit > of sub-kinding. In particular > > error :: forall a. String -> a > > We want to allow > error "foo" :: Int# I have subkinding in my calculus as well, but in a completely different context. For instance, the kind of Either is + -> + -> * because Either is covariant in its arguments. But the kind of Either is also x -> x -> * (x=invariance). So we have + -> + -> * as the most specific kind of Either. Note, that the kind arrow in my system is contravariant as well. I think, that is a nice analogy to the type system. For example, let tau_1:(x -> *) -> *, tau_2:(+ -> *) -> *. Then tau_1 is usable whenever tau_2 is in operation. So from (+ -> *) <: (x -> *) it follows in my system, that (x -> *) -> * <: (+ -> *) -> *. Unfortunately I have to decide two contexts of the kind arrow. To understand this, consider my definition of kinds: Def.: Kinds are inductively defined as follows: * is a kind if kappa1 and kappa2 are kinds, then kappa1 -> kappa2 is a kind if kappa is a kind, then + -> kappa, - -> kappa, x -> kappa and alpha -> kappa alpha is a so-called kind variable, that can be instantiated by +, - or x (not by arbitrary kinds!). Further on, we have the convention, that * -> kappa has to be seen as x -> kappa. What do we mean by the term kind variable? A type tau may have the kind (alpha->beta->*)->alpha->beta->*. If one applies this type, e.g., to the arrow type constructor one gaines (tau (->)): - -> + -> *. So information about variances is propagated. This allows for subtyping in a convenient manner. > so the kind of 'a' can't be *, nor # (the kind of unboxed types). It's > an "open" kind, written "?"; both * and # are sub-kinds of ?. I have read about this issue in the sources of the GHC. I try to understand... > You should nevertheless be able to encode your kind system in the same > way as GHC does. This is a pity, because my kind system allows for a really nice type inference algorithm, that can deal with higher-kinded types properly. I hope, that I can transfer it to the GHC. I will write a short section for the commentary as soon as I completely understand the GHC kind system. > But I have been thinking that it's over-kill to use Types for Kinds, and > leads to no real saving. I think so, too, because the system from "Typing Haskell in Haskell" is very easy to understand and extend. Another advantage is, that it is closer to the Haskell report. > I may well split the two types in the future. This would be great. Thank you for the informations, Steffen Mazanek

1 0

DrIFT 2.0.1
by John Meacham 29 Oct '03

29 Oct '03

I know it has been a while, but DrIFT 2.0.1 is out. http://repetae.net/john/computer/haskell/DrIFT/ some improvments are: DrIFT-2.0.1: * fixed many warnings in generated code * support for strict fields in constructors * support for infix constructors * added help messages and categorization to rules * small isLiterate fix (TODO use nhcs deliterizer) * prints debug info in comment in chaseImports * code cleanups * integrated some changes from Strafunski-DrIFT 1.7 * autoconf/automake improvements -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

1 0

literate comments
by Steffen Mazanek 28 Oct '03

28 Oct '03

Hello, in the Haskell report the latex code environment is mentioned: http://www.haskell.org/onlinereport/literate.html Would it make sense, to add a xml like code environment as well, e.g., <code>...</code>? Ciao, Steffen

5 5

[Cfp] Workshop on Practical Aspects of High-level Parallel Programming (PAPP 2004)
by F. Loulergue 27 Oct '03

27 Oct '03

======================================================================== ==== Workshop on Practical Aspects of High-level Parallel Programming (PAPP 2004) http://f.loulergue.free.fr/PAPP2004 part of The International Conference on Computational Science http://www.cyfronet.krakow.pl/iccs2004/ June 7-9, 2004, Kraków, Poland Aims and scope 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 (algorithmic skeletons, parallel extensions of functional languages, such as Haskell and ML, or parallel logic and constraint programming, parallel execution of declarative programs such SQL queries, etc.) has produced methods and tools that improve the price/performance ratio of parallel software, and broaden the range of target applications. Several emerging domains, such as Grid Computing, are currently raising new issues. GRIDs offer 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. The PAPP workshop focuses on practical aspects of high-level parallel programming: design, implementation and optimization of high-level programming languages and tools (performance predictors working on high-level parallel/grid source code, visualisations of abstract behaviour, automatic hotspot detectors, high-level GRID resource managers, compilers, automatic generators, etc.), applications in all fields of high-performance computing, benchmarks and experiments. Research on high-level grid programming is particularly relevant. Topics We welcome submission of original, unpublished papers in English on topics including: - high-level programming models and tools for GRID computing - high-level parallel language design, implementation and optimisation - functional, logic, constraint programming for parallel, distributed and Grid systems - algorithmic skeletons and high level parallel libraries - generative (e.g. template-based) programming with algorithmic skeletons and high level parallel libraries - applications in all fields of high-performance computing (using high-level tools) - benchmarks, experiments using such languages and tools Paper submission and publication Prospective authors are invited to submit full papers in English presenting original research. Submitted papers must be unpublished and not submitted for publication elsewhere. Papers will go through a rigorous reviewing process. Each paper will be reviewed by at least two referees. The accepted papers will be published in the Springer-Verlag LNCS series, as part of the ICCS proceedings. Papers (PDF file) should be sent to loulergue(a)univ-paris12.fr with subject "[PAPP Workshop] Submission" no later than Monday 8 December 2003. We invite you to submit a full paper of 6 to 10 pages (A4), describing new and original results. The submitted paper must be formatted according to the rule of Lecture Notes in Computer Science (LNCS). Submission implies the willingness of at least one of the authors to register and present the paper. An early email with your intention to submit a paper would be greatly appreciated (especially if you have doubts about the relevance of your paper). Important Dates December 8, 2003 (FIRM DEADLINE) Full paper due January 9, 2004 Notification Februray 10, 2004 Camera-ready paper due Programme committee Rob Bisseling (Univ. of Utrecht, The Netherlands) Matthieu Exbrayat (Univ. of Orléans, France) Clemens Grelck (Univ. of Lübeck, Germany) Kevin Hammond (Univ. of St. Andrews, UK) Zhenjiang Hu (Univ. of Tokyo, Japan) Frédéric Loulergue (Univ. Paris Val de Marne, France) Quentin Miller (Miller Research Ltd., UK) Susanna Pelagatti (Univ. of Pisa, Italy) Alexander Tiskin (Univ. of Warwick, UK) Chair and Organizer Dr. Frédéric LOULERGUE Laboratory of Algorithms, Complexity and Logic (LACL) University of Paris Val de Marne 61, avenue du Général de Gaulle F-94010 CRÉTEIL - FRANCE loulergue(a)univ-paris12.fr ======================================================================== ====

1 0

REMINDER - Contributions to HC&A Report (November 2003 edition)
by C.Reinke 27 Oct '03

27 Oct '03

Dear Haskeller, *you* are still envited to let the Haskell community know what you've been doing with Haskell recently! Remember, in spite of its printable formats, this is still basically an email survey: - just hit the reply button now, and take a few minutes to compose your contribution about your own recent Haskell work and play (ASCII-format is fine, LaTeX is fine - please do not send HTML..). - if you know of someone else doing interesting stuff with Haskell (perhaps even at work?-), who is not yet confirmed on our topics and contributors list below, let them know about this survey, and encourage them to contribute (please cc me, so that I know what contributions to expect) As you can see from the topics and contributors page for our Haskell Communities & Activities Reports, at: http://www.haskell.org/communities/topics.html both confirmations from well-known contributors and offers from new contributors are still a bit sparse at this stage, although we're making progress (I'm delighted to see that most contributors send their text with their confirmation - thanks!-). ----------------------------------------------------------------- Haskell Communities and Activities Report (November 2003 edition) http://www.haskell.org/communities/ Could everybody send in their individual reports ** by the end of THIS week ** ? Please?-) ----------------------------------------------------------------- Thanks, Claus (current editor) -- Haskell Communities and Activities Report (November 2003 edition) Contributions are due in by the end of THIS week! http://www.haskell.org/communities/

1 0

Call for papers: Fourth International Workshop on Reduction Strategies in Rewriting and Programming (WRS'04)
by Sergio Antoy 27 Oct '03

27 Oct '03

=============================================================== We apologize for multiple copies of this call for participation =============================================================== ******************************** * * * WRS'04 CALL FOR PAPERS * * * ******************************** http://www-i2.informatik.rwth-aachen.de/WRS04/ The Fourth International Workshop on Reduction Strategies in Rewriting and Programming (WRS'04) will be held on June, 2, 2003, in Aachen, Germany, as a part of the Federated Conference on Rewriting, Deduction, and Programming (RDP'04). IMPORTANT DATES: March 17, 2004 Deadline for electronic submission of papers April 14, 2004 Notification of acceptance of papers May 2, 2004 Deadline for final versions of accepted papers June 2, 2004 Workshop TOPICS include, but are not restricted to: * theoretical foundations for the definition and semantic description of reduction strategies * strategies in different frameworks (term rewriting, graph rewriting, infinitary rewriting, lambda calculi, higher order rewriting, conditional rewriting, rewriting with built-ins, narrowing, constraint solving, etc.) and their application in (equational, functional, functional-logic) programming (languages) * properties of reduction strategies / computations under strategies (e.g., completeness, computability, decidability, complexity, optimality, (hyper-)normalization, cofinality, fairness, perpetuality, context-freeness, neededness, laziness, eagerness, strictness) * interrelations, combinations and applications of reduction under different strategies (e.g., evaluation mechanisms in programming languages, equivalence conditions for fundamental properties like termination and confluence, applications in modularity analysis, connections between strategies of different frameworks, etc.) * program analysis and other semantics-based optimization techniques dealing with reduction strategies * rewrite systems / tools / implementations with flexible / programmable strategies as essential concept / ingredient * specification of reduction strategies in (real) languages * tutorials and systems related to evaluation strategies INVITED TALKS will be given by: * Olivier Danvy (University of Aarhus, Denmark), Normalization by Evaluation * Jan Willem Klop (Vrije Universiteit Amsterdam, The Netherlands), Reduction Cycles PROGRAM COMMITTEE: Sergio Antoy Portland (USA) (co-chair) Roberto Di Cosmo Paris VII (France) Juergen Giesl Aachen (Germany) Bernhard Gramlich Wien (Austria) Salvador Lucas Valencia (Spain) Aart Middeldorp Innsbruck (Austria) Jaco van de Pol Amsterdam (The Netherlands) Pierre Rety Orleans (France) Amr Sabry Bloomington (USA) Yoshihito Toyama Sendai (Japan) (co-chair) SUBMISSIONS: We solicit papers on all aspects of reduction strategies in rewriting and programming. Submissions should describe unpublished work, except for survey papers which are explicitly welcome, too. Submissions should not exceed 10 pages (however, survey papers may be longer) and be sent in PostScript or PDF format to the PC co-chairs at wrs04(a)redstar.cs.pdx.edu by March 17, 2004. The use of the style file available from the RDP workshop style page is encouraged. The call-for papers is also available in PDF format. Submissions should include the title, authors' names, affiliations, addresses, and e-mail. Selection of papers by the PC will be based on originality, significance, and correctness. Final versions will be due by May 2, 2004. PUBLICATION: Accepted papers will be included in the preliminary workshop proceedings that will be available at the workshop. The final workshop proceedings will be published in Elsevier's Electronic Notes in Theoretical Computer Science (ENTCS) series. For further questions please contact the program co-chairs: Sergio Antoy and Yoshihito Toyama at wrs04(a)redstar.cs.pdx.edu.

1 0

I/O multiplexing
by Peter Simons 27 Oct '03

27 Oct '03

Hi, I have a question concerning "manual" I/O multiplexing in Haskell, or specifically with GHC. I have written an interface to the C library ADNS, which performs asynchronous DNS queries. Everything is fine and dandy, but now comes the hard part: The function foreign import ccall adns_beforepoll :: State -- ADNS context -> Ptr Pollfd -- space for 'n' Pollfd -> Ptr CInt -- n -> Ptr CInt -- max timeout -> Ptr (Timeval) -- current time -> IO CInt generates an array of file descriptors, suitable for calling poll(2). The function foreign import ccall adns_afterpoll :: State -> Ptr Pollfd -> CInt -> Ptr (Timeval) -> IO CInt scans this array (after poll has been called), performs I/O on all readable/writable sockets, and processes any packets that have been received. Obviously, the library wants me to call poll myself, though. But since poll is not supported by Haskell's run-time system, the call would block _all_ running threads in my process, not just the thread doing the DNS resolving. I have considered the following options to solve this: 1. Run the DNS resolver in a forkOS thread. 2. Declare all imported functions to be thread-safe (what they are) and use forkIO. 3. Call poll(2) without blocking, then conjure some magic to decide when to call it again without busy polling. 4. Register the file descriptors with GHC's internal poll event loop. Option (1) seems to be straight-forward, but I don't want to rely on the non-standard forkOS function unless I really have to. The same goes for (4): This is probably a good solution, but it's not portable among compilers. (3) works fine, but is unsatisfactory because the resolver will have comparably large latency times. (I have been processing DNS queries every, say, second.) So option (2) seems quite attractive compared to the others ... But the question is: Would that even work? Any ideas, thoughts, recommendations? Peter

1 0

[Caml-list] IBM funding for OCaml on Eclipse? (fwd)
by Hal Daume III 26 Oct '03

26 Oct '03

Perhaps someone one this list might find this interesting... -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume ---------- Forwarded message ---------- Date: Sat, 25 Oct 2003 22:18:59 -0700 From: Greg K <lists(a)gak.com> To: caml-list(a)inria.fr Subject: [Caml-list] IBM funding for OCaml on Eclipse? Anyone want to do something with OCaml on Eclipse? IBM has a million dollars in grants for teaching and research efforts done with their extensible open source IDE. (I currently use it for Java work - its very good, reminds me of Smalltalk dev environments.) It's designed to be extensible to support other languages (currently has a strong working C++ extension, and many other languages coming along). Any OCaml proposals should probably include some work to allow Java and OCaml runtimes to inter-operate. Proposals are due by November 7th. http://www-3.ibm.com/software/info/university/products/eclipse/eig.html ------------------- To unsubscribe, mail caml-list-request(a)inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

1 0