- Haskell - Haskell.org

changed link
by Christian Maeder 15 Oct '03

15 Oct '03

Hi, on: http://www.haskell.org/bookshelf/ the link for: Online Haskell Course by Ralf Hinze (in German). should be changed from: http://www.informatik.uni-bonn.de/~ralf/teaching/HsKurs_toc.html to: http://www.informatik.uni-bonn.de/~ralf/teaching/Hskurs_toc.html At least my browser seems to be case sensitive. Christian

2 1

Re: IO behaves oddly if used nested
by blaat blaat 14 Oct '03

14 Oct '03

[snip] > Neither example is odd behavior, unless >you consider Hugs providing a perfectly reasonable instance of Show for >IO a odd. True, every program behaves exactly as according to the definition of the run-time behavior of Haskell programs. (Hugs deviates a bit from ghc but ah well) The odd is not in the run-time behavior. The odd is in the conceptual explanation. If I give a description of some f x = y function in Haskell I expect that some program f x is reduced to y and the result is given back (possibly printed). A good story to sell to students. This is almost everywhere the case except for the IO monad. In the former example, the inner putStr is _not_ evaluated but a message is shown (hinting that a IO has some structure we can observe before evaluation). In the latter example, it is shown that we are not interested in a result of a IO program, but only in its (lazily generated) side-effects. The monad behaves oddly with respect to the f x = y behavior. I think I observe the following reactions when I explain IO: 1* Can't the guy in front of me stop poking his nose? (the blank faces and parse errors) 2* Hmm, feels like Java, looks like Java, ahah! is Java! (coders) 3* Hmm, feels like math, looks like math, ahah! is math! (designers and thinkers) Group 1 will mimic, group 2 will produce obfuscuated Java code in Haskell, group 3 has great difficulty with the IO monad (although they are the first group who will write OK haskell programs) because it behaves differently from what they expect. The usual questions of group 3: * Why is an IO a evaluated if I am not interested in it's result? (opposite to the f x = y lazy behavior) * Why is in the putStr "hello world" example Hello World not shown? (opposite to expected f x = y eval-first-then-show behavior) * Why is in the IO (IO ()) example the inner IO () not evaluated? (somewhat opposite to expected f (f x) behavior - I personally wonder if it is even sound in a category theoretical setting) * ...Lots of other questions... Hmm, have to finish this email now - time constraints. I guess the short story just is: IO monads == sometimes bad conceptual story to sell. Especially so since the "best" group has the biggest problems and non-trivial examples are only explainable in the end in terms of run-time behavior. What was that remark again about pointy headed people and Haskell? ;-) For that I also gave the Nomad datatype as a possible solution (needs a pretty hefty type checker though). A nice (old) idea would be to represent IO as programs which are interpreted by some _outside_ RTS in a given manner, and leave the Haskell language clean. (It might even be a good idea with respect to the compiler implementation since it removes checking against unsafe IO behavior from the compiler -- just a thought) Bye now, and cheers, l4t3r _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

3 2

Re: About Haskell Thread Model
by Wolfgang Thaller 14 Oct '03

14 Oct '03

> I am a new learner of Haskell and I am interested in Haskell's > concurrent model. Can somebody give me a brief intro about Haskell's > thread model, like how the use-level threads are mapped to kernel > thread > and what scheduling mechanism that Haskell uses, or point me to some > links or documents that I can learn from. In the interpreter Hugs, all Haskell threads are run in one kernel thread. They are scheduled cooperatively; thread switches only take place when a function from the "Concurrent" module is called. In the currently released version of GHC, all Haskell threads are run in one kernel thread, too; however, thread switches can take place whenever memory is allocated --- and in Haskell, that means "almost always". The optimizer manages to compile a fibonacci function that doesn't allocate any memory, but in the real world, it's as good as real preemption. If you compile the bleeding-edge GHC from the CVS HEAD, you'll get something else; while "most" threads (those created using "forkIO") are still light-weight threads that are scheduled in just one kernel thread, you can also create threads that get their own operating system thread. This is solves all the problems that lightweight threads can have with foreign (i.e. non-Haskell) libraries. You should also note that no Haskell implementation currently supports SMP; even when multiple kernel threads are used, there is a mutual exclusion lock on the Haskell heap, so a multithreaded Haskell program will use only one CPU on an SMP system. I hope my answer was useful... Cheers, Wolfgang P.S.: If you want to do me a favour, you could tell your mail program not to send multipart or HTML messages to the list; they look terrible to people like me who get a daily digest from the mailing list.

3 6

CFP for LDTA 2004
by jas＠di.uminho.pt 13 Oct '03

13 Oct '03

Apologies if you receive multiple copies of this message. ********************************************************** *** Fourth Workshop on *** *** Language Descriptions, Tools and Applications *** *** LDTA 2004 *** *** *** *** APRIL, 3, 2004 *** *** BARCELONA, SPAIN *** *** *** *** http://www.di.uminho.pt/LDTA04 *** ********************************************************** Scope: ------ The aim of this one day workshop is to bring together researchers from academia and industry interested in the field of formal language definitions and language technologies, with a special emphasis on tools developed for or with these language definitions. Some of the scientific areas that take advantage from these active research fields are: - Program analysis, transformation, generation - Formal analysis of language properties - Automatic generation of language processing tools For example, language definitions can be augmented in a manner so that not only compilers and interpreters can be automatically generated but also other tools such as syntax-directed editors, debuggers, partial evaluators, test generators, documentation generators, etc. These beneficial results are well known and we would like to make them widely exploited in current practice. Domains of applications that are of interest for this workshop are among others: - Language components, modeling languages - Re-engineering, re-factoring - Aspect-oriented programming, adaptive programming - Domain-specific languages - XML processing - Visualization and graph transformation The workshop welcomes contributions on all aspects of formal language definitions, with special emphasis on applications and tools developed for or with these language definitions. We also encourage contributions on the use of these methodologies in education. Tool demonstrations: -------------------- The one day LDTA 2004 workshop program will also include a session on tool demonstrations. Submission procedure and publication: ------------------------------------- Authors should submit a full paper (15-20 pages) to LDTA 2004 program committee chairs. Tool demo papers (2 pages) should also be submitted to the PC chairs. Further information will be available at the LDTA 2004 home page. 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. Author's instructions are given here. The authors of the best papers will be invited to write a journal version of their paper which will be separately reviewed and after acceptance be published in a special issue devoted to LDTA 2004 of the journal Science of Computer Programming (Elsevier Science). Organizing Committee: --------------------- Isabelle Attali, INRIA Sophia Antipolis, France Thomas Noll, Aachen University of Technology, Germany Joao Saraiva, University of Minho, Portugal Program committee co-chairs: ---------------------------- Gorel Hedin, Lund Institute of Technology, Sweden Eric Van Wyk, University of Minnesota, USA Program Committee members: -------------------------- John Boyland, University of Wisconsin, USA Olivier Danvy, University of Aarhus, Denmark Jose Labra Gayo, Oviedo University, Spain Paul Klint, CWI, The Netherlands Jens Knoop, Vienna University of Technology, Austria Erik Meijer, Microsoft Research, USA Didier Parigot, INRIA, France Paul Roe, QUT, Australia Ganesh Sittampalam, Oxford University Computing Laboratory, England Anthony Sloane, Macquarie University, Australia Yannis Smaragdakis, Georgia Institute of Technology, USA Doaitse Swierstra, Utrecht University, The Netherlands Kris de Volder, University of British Columbia, Canada ----------------------------------------------------------------------- IMPORTANT DATES ----------------------------------------------------------------------- December 1st 2003 Submission of full paper January 5th 2004 Submission of a tool demo paper January 15th 2004 Notification February 15th 2004 Final version due April 3rd 2004 LDTA 2004

1 0

RE: About Haskell Thread Model
by Yang, Qing 13 Oct '03

13 Oct '03

Wolfgang, According to the User Guide of GHC 6.1 that GHC supports both Concurrent Haskell and Parallel Haskell. And Concurrent Haskell and Parallel Haskell have very different purpose. To my understanding about the document and your reply, it's Concurrent Haskell who uses Threads to process tasks concurrently and the threads are actually user-level thread. And no SMP is supported now in Concurrent Haskell. Is this right? For Parallel Haskell, it is said in the User Guide document as follows: ----------------------- Parallel Haskell is about speed - spawning threads onto multiple processors so that your program will run faster. ...... A Parallel Haskell program implies multiple processes running on multiple processors, under a PVM (Parallel Virtual Machine) framework. ...... ------------------------ Do you have some experience or knowledge about Parallel Haskell? And what you mentioned in you previous email is all about Concurrent Haskell or about the both? Thanks, Qing Yang System Software Lab Intel Corporation qing.yang(a)intel.com 86-10-85298800 Ext. 1955 (Office) 8751-1955 (iNet) -----Original Message----- From: Wolfgang Thaller [mailto:wolfgang.thaller@gmx.net] Sent: Sunday, October 12, 2003 4:58 AM To: Yang, Qing Cc: haskell(a)haskell.org Subject: Re: About Haskell Thread Model > I am a new learner of Haskell and I am interested in Haskell's > concurrent model. Can somebody give me a brief intro about Haskell's > thread model, like how the use-level threads are mapped to kernel > thread > and what scheduling mechanism that Haskell uses, or point me to some > links or documents that I can learn from. In the interpreter Hugs, all Haskell threads are run in one kernel thread. They are scheduled cooperatively; thread switches only take place when a function from the "Concurrent" module is called. In the currently released version of GHC, all Haskell threads are run in one kernel thread, too; however, thread switches can take place whenever memory is allocated --- and in Haskell, that means "almost always". The optimizer manages to compile a fibonacci function that doesn't allocate any memory, but in the real world, it's as good as real preemption. If you compile the bleeding-edge GHC from the CVS HEAD, you'll get something else; while "most" threads (those created using "forkIO") are still light-weight threads that are scheduled in just one kernel thread, you can also create threads that get their own operating system thread. This is solves all the problems that lightweight threads can have with foreign (i.e. non-Haskell) libraries. You should also note that no Haskell implementation currently supports SMP; even when multiple kernel threads are used, there is a mutual exclusion lock on the Haskell heap, so a multithreaded Haskell program will use only one CPU on an SMP system. I hope my answer was useful... Cheers, Wolfgang P.S.: If you want to do me a favour, you could tell your mail program not to send multipart or HTML messages to the list; they look terrible to people like me who get a daily digest from the mailing list.

3 2

TPLP Special Issue on Verification
by Sandro.Etalle＠cwi.nl 13 Oct '03

13 Oct '03

TPLP Special Issue on Specification, Analysis and Verification of Reactive Systems http://www.cs.utwente.nl/~etalle/specialissue.html Motivations and Goals The huge increase in interconnectivity we have witnessed in the last decade has boosted the development of systems which are often large-scale, distributed, time-critical, and possibly acting in an unreliable or malicious environment. Furthermore, software and hardware components are often mobile, and have to interact with a potentially arbitrary number of other entities. These systems require solid formal techniques for their specification, analysis and verification. In this respect, computational logic plays an increasingly important role. Concerning the specification aspect, one can think for instance at the specification, in temporal logic, of a communication protocol. Such specification offers the advantage that one can reason about it using formal methods, and at the same time it is often easily executable by rewriting it into a logic-based programming language. In addition, Computational logic plays a fundamental role by providing formal methods for proving system's correctness and tools - e.g. using techniques like constraint programming and theorem proving - for verifying their properties. This special issue is inspired to the ICLP workshops on "Specification, Analysis and Verification of Emerging technologies (SAVE)" that took place during iclp 2001 and iclp 2002. Nevertheless, submission is open to everyone. TOPICS The topics of interest include but are not limited to: * Specification languages and rapid prototyping: * Logic programming and its extensions * First-order, constructive, modal and temporal logic * Constraints * Type theory * Analysis: * Abstract interpretation * Program analysis and transformation * Validation: * Simulation and testing * Deductive methods * Model checking * Theorem proving The preferred issues include, but are not limited to: * Security: e.g. specification and verification of security protocols. * Mobility: specification and verification of mobile code. * Interaction, coordination, negotiation, communication and exchange on the Web. * Open and Parametrized Systems. SUBMISSIONS: Only electronic submission can be accepted. Please send your contribution in pdf or PostScript format to giorgio(a)disi.unige.it. DATES: Deadline for submission: November 15, 2003 Notification: May 1, 2003 Revised paper due: October 1, 2004 Publication: 2005 Authors of submitted papers are encouraged to post their articles at CoRR, thereby helping timely distribution of the scientific works. EDITORS - Giorgio Delzanno, University of Genova, Italy, http://www.disi.unige.it/person/DelzannoG/ - Sandro Etalle, University of Twente and CWI Amsterdam, the Netherlands, http://www.cs.utwente.nl/~etalle/ - Maurizio Gabbrielli, University of Bologna, Italy, http://www.cs.unibo.it/~gabbri/ ABOUT TPLP Theory and Practice of Logic Programming (TPLP, see http://uk.cambridge.org/journals/tlp/ and http://www.cwi.nl/projects/alp/TPLP/index.html) is published by the Cambridge University Press (http://uk.cambridge.org/) and is the sole official journal of the Association for Logic Programming (http://www.cwi.nl/projects/alp)

1 0

nitpicking?
by Janis Voigtlaender 13 Oct '03

13 Oct '03

Hello, just as an addition to the discussion (one week ago or so) about Haskell being defined as a non-strict rather than lazy language: in that context it struck me as odd that Section 6.2 of the Report says `seq` is used to avoid "unneeded laziness". The only other uses of "lazy" seem to appear in the context of irrefutable patterns, getContents, and a source comment for the function transpose in the List library. Ciao, Janis. -- Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

1 0

RE: About Haskell Thread Model
by Yang, Qing 13 Oct '03

13 Oct '03

Thanks very much. It's very useful. PS: Sorry for the inconvenience I think I should have sent the mail in plain text. Qing -----Original Message----- From: Wolfgang Thaller [mailto:wolfgang.thaller@gmx.net] Sent: Sunday, October 12, 2003 4:58 AM To: Yang, Qing Cc: haskell(a)haskell.org Subject: Re: About Haskell Thread Model > I am a new learner of Haskell and I am interested in Haskell's > concurrent model. Can somebody give me a brief intro about Haskell's > thread model, like how the use-level threads are mapped to kernel > thread > and what scheduling mechanism that Haskell uses, or point me to some > links or documents that I can learn from. In the interpreter Hugs, all Haskell threads are run in one kernel thread. They are scheduled cooperatively; thread switches only take place when a function from the "Concurrent" module is called. In the currently released version of GHC, all Haskell threads are run in one kernel thread, too; however, thread switches can take place whenever memory is allocated --- and in Haskell, that means "almost always". The optimizer manages to compile a fibonacci function that doesn't allocate any memory, but in the real world, it's as good as real preemption. If you compile the bleeding-edge GHC from the CVS HEAD, you'll get something else; while "most" threads (those created using "forkIO") are still light-weight threads that are scheduled in just one kernel thread, you can also create threads that get their own operating system thread. This is solves all the problems that lightweight threads can have with foreign (i.e. non-Haskell) libraries. You should also note that no Haskell implementation currently supports SMP; even when multiple kernel threads are used, there is a mutual exclusion lock on the Haskell heap, so a multithreaded Haskell program will use only one CPU on an SMP system. I hope my answer was useful... Cheers, Wolfgang P.S.: If you want to do me a favour, you could tell your mail program not to send multipart or HTML messages to the list; they look terrible to people like me who get a daily digest from the mailing list.

1 0

Re: About Haskell Thread Model
by Bill Halchin 12 Oct '03

12 Oct '03

2 1

ANNOUNCE: Cryptographic Library for Haskell
by Dominic Steinitz 11 Oct '03

11 Oct '03

I would like to annouce the second release of the Haskell Cryptographic Library (0.3.3). See http://www.haskell.org/crypto/ReadMe.html for more details. This library collects together existing Haskell cryptographic functions and augments them so that they: · Have common type signatures. · Can be used with the standard mode and padding algorithms (in the case of block mode ciphers). This release contains: · DES · Blowfish · Cipher Block Chaining (CBC) mode · PKCS5 and nulls padding · SHA-1 · RSA · OAEP Dominic Steinitz

1 0