From ppk at cse.iitk.ac.in Sun Mar 1 01:25:06 2009 From: ppk at cse.iitk.ac.in (Piyush P Kurur) Date: Sun Mar 1 01:14:00 2009 Subject: [Haskell] haskell documentation Message-ID: <20090301062506.GA9165@cse.iitk.ac.in> Hi, I am a Arch linux + GHC user. I found it difficult to download documentations for GHC and all the modules. The GHC site does not seem to have a single tar.gz file by which one could down load the entire documentation tree. Same problem for modules build via yaourt. Of course one could build it directly from the appropriate cabal package but is there an automatic way via pacman/yaourt for example ? Regards ppk From jude at pwan.org Sun Mar 1 08:36:54 2009 From: jude at pwan.org (Jude) Date: Sun Mar 1 08:25:40 2009 Subject: [Haskell] Announcement: A Haskell binding for the Augeas API Message-ID: All, I've published a Haskell FFI binding for the Augeas configuration editing API on Hackage. Please let me know if you find any problems with anything. Cheers, Jude Links ===== Hackage http://hackage.haskell.org/cgi-bin/hackage-scripts/package/augeas Source: http://code.haskell.org/augeas/ Bugs: http://trac.haskell.org/augeas/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090301/aca77cc8/attachment.htm From xj2106 at columbia.edu Sun Mar 1 12:08:02 2009 From: xj2106 at columbia.edu (Xiao-Yong Jin) Date: Sun Mar 1 11:57:10 2009 Subject: [Haskell] haskell documentation In-Reply-To: <20090301062506.GA9165@cse.iitk.ac.in> (Piyush P. Kurur's message of "Sun, 1 Mar 2009 11:55:06 +0530") References: <20090301062506.GA9165@cse.iitk.ac.in> Message-ID: <87y6vpqih9.fsf@columbia.edu> ppk@cse.iitk.ac.in (Piyush P Kurur) writes: > Hi, > > I am a Arch linux + GHC user. I found it difficult to download > documentations for GHC and all the modules. The GHC site does not seem > to have a single tar.gz file by which one could down load the entire > documentation tree. > > Same problem for modules build via yaourt. Of course one could build > it directly from the appropriate cabal package but is there an > automatic way via pacman/yaourt for example ? I guess you can always add `runhaskell Setup.lhs haddock' or even `runhaskell Setup.lhs hscolour' in the PKGBUILD. Should that be the default? I'm not sure. Xiao-Yong -- c/* __o/* <\ * (__ */\ < From jgm at berkeley.edu Sun Mar 1 14:21:40 2009 From: jgm at berkeley.edu (John MacFarlane) Date: Sun Mar 1 14:10:26 2009 Subject: [Haskell] ANN: pandoc 1.2 Message-ID: <20090301192139.GC26057@berkeley.edu> I'm pleased to announce the release of pandoc version 1.2 (uploaded today to HackageDB). The most significant new feature is support for literate Haskell. You can now use pandoc directly on literate Haskell source files to produce syntax-highlighted HTML output: pandoc -s MyProg.lhs > MyProg.html Pandoc will interpret text sections as (extended) markdown. If you prefer to write literate Haskell using reStructuredText or LaTeX, pandoc supports that too: pandoc -s --from rst+lhs MyProg.lhs > MyProg.html pandoc -s --from latex+lhs MyProg.lhs > MyProg.html You can even convert from one style to another: pandoc -s --from markdown+lhs --to latex+lhs MyProg.hs This release also adds an '--email-obfuscation' option, so the user can select an email obfuscation method (or disable obfuscation), and support for citations using the latest version of Andrea Rossato's citeproc-hs. In addition, many bugs have been fixed. Thanks to everyone who filed bug reports. John From haskell at list.mightyreason.com Sun Mar 1 17:36:20 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Sun Mar 1 17:25:09 2009 Subject: [Haskell] major speed improvement: regex-tdfa reaches 1.0.0 Message-ID: <49AB0DE4.2020706@list.mightyreason.com> Announcing the version 1.0.0 release of regex-tdfa. I am proud of this release. This is not just a bug fix release. It is a serious improvement in the asymptotic running time. The previous versions allowed bad combinations of pattern and searched text length to scale badly in the length of the text. Previously the worst case for text of length N was O(N^3). The new worst case asymptotic runtime scaled as O(N). There is never any backtracking. And the worst case storage space is independent of N. The package is on hackage at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa The darcs repository is at http://darcs.haskell.org/packages/regex-unstable/regex-tdfa/ All non-overlapping matches are found and returned, along with all captured (parenthesized) subexpressions. The result is precisely what Posix extended regular expressions are supposed to return. To be concrete, consider example text with length of N of (2^n)+2: > longInput = replicate (2^n) 'a' ++ "bc" And define 4 worst-case-scenario patterns. I wrote the code and I know how to kill it: > wcs0 = "a*b" > wcs1 = "a*c" > wcs2 = "(a|aa)*b" > wcs3 = "(a|aa)*c" wcs0 is easy. wcs1 causes the old code to backtrack. wcs2 causes the old code's storage to scale as O(N). wcs3 causes both backtracking and O(N) storage with the old code. The old code's time scales as O(N) for wcs0, O(N^2) for wcs1 and wcs2, and O(N^3) for wcs3. The new code is always O(N). The actual timings for the old code on my G4 laptop for wcs on 2^8 and 2^9 and 2^10 are: Reason:compare-tdfa chrisk$ time ./Test-TDFA-np wcs3 8 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA-np wcs3 8 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(257,1)),(1,(-1,0))]] 263,776,756 bytes allocated in the heap user 0m1.017s sys 0m0.058s Reason:compare-tdfa chrisk$ time ./Test-TDFA-np wcs3 9 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA-np wcs3 9 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(513,1)),(1,(-1,0))]] 1,998,647,452 bytes allocated in the heap user 0m7.083s sys 0m0.289s Reason:compare-tdfa chrisk$ time ./Test-TDFA-np wcs3 10 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA-np wcs3 10 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(1025,1)),(1,(-1,0))]] 15,653,277,200 bytes allocated in the heap user 0m53.350s sys 0m2.056s The doubling of length is causing a nearly eight-fold time increase. The heap allocation is also increasing nearly eight-fold. The new code with the same input pattern and texts gives: Reason:compare-tdfa chrisk$ time ./Test-TDFA2-0.99.19-np2 wcs3 8 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA2-0.99.19-np2 wcs3 8 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(257,1)),(1,(-1,0))]] 2,135,324 bytes allocated in the heap user 0m0.017s sys 0m0.017s Reason:compare-tdfa chrisk$ time ./Test-TDFA2-0.99.19-np2 wcs3 9 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA2-0.99.19-np2 wcs3 9 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(513,1)),(1,(-1,0))]] 3,588,656 bytes allocated in the heap user 0m0.024s sys 0m0.017s Reason:compare-tdfa chrisk$ time ./Test-TDFA2-0.99.19-np2 wcs3 10 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA2-0.99.19-np2 wcs3 10 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(1025,1)),(1,(-1,0))]] 6,345,436 bytes allocated in the heap user 0m0.038s sys 0m0.018s Note that the heap allocation for the 1026 character example above is 2466 times less than the old code. That was too fast to prove the scaling, so take more input: Reason:compare-tdfa chrisk$ time ./Test-TDFA2-0.99.19-np2 wcs3 20 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA2-0.99.19-np2 wcs3 20 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(1048577,1)),(1,(-1,0))]] 5,708,574,848 bytes allocated in the heap user 0m26.023s sys 0m0.985s Reason:compare-tdfa chrisk$ time ./Test-TDFA2-0.99.19-np2 wcs3 21 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA2-0.99.19-np2 wcs3 21 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(2097153,1)),(1,(-1,0))]] 11,416,354,056 bytes allocated in the heap user 0m52.656s sys 0m1.985s The length and time both doubled, as did the heap allocation. And the new code has searched two million characters in the time the old code searched one thousand. How about away from the worst case scenario? On the testing suite the new code is running slightly slower: Reason:compare-tdfa chrisk$ time ./Test-TDFA-np -r 1 100 > /dev/null user 0m4.841s sys 0m3.019s Reason:compare-tdfa chrisk$ time ./Test-TDFA2-0.99.19-np2 -r 1 100 > /dev/null user 0m5.970s sys 0m3.012s So that is an increase of execution time of 14%. This small dip in performance might be reclaimable with more optimization. I think the gain in worst case performance already offsets the slight cost. The code for String is complete. The strict and lazy bytestrings and the (Seq Char) are currently using the String code for matching. This will be improved in a future release. Cheers, Chris The small print: regex-tdfa will still behave badly in space and time if given a pathological pattern, e.g. "(((a|aa){0,100}){0,100}){0,100}". But, I am hopeful than I can improve regex-tdfa to behave well with the patterns like this one. That is my vague goal for a future version 2.0.0 release. The very small print: I have been using ghc-6.10.1, and I think I have carried over cabal switches to make ghc-6.8.3 also work. The library probably can work with ghc-6.6, but the cabal file will need editing first as well as fixes to "Text.Regex.TDFA.NewDFA.copySTU". From DekuDekuplex at Yahoo.com Mon Mar 2 02:44:10 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Mon Mar 2 02:33:47 2009 Subject: [Haskell] Re: Take a break: write an essay for Onward! Essays References: <638ABD0A29C8884A91BC5FB5C349B1C33399201B74@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Thu, 12 Feb 2009 09:41:49 +0000, Simon Peyton-Jones wrote: >PS: To get your imagination going, here are a couple of (strongly-contrasting) past essays: > * Dan Grossman "The transactional memory / garbage collection analogy" > http://www.cs.washington.edu/homes/djg/papers/analogy_oopsla07.pdf > * Dick Gabriel "Designed as designer" > http://dreamsongs.org/DesignedAsDesigner.html One other sample essay mentioned, which I personally find to be quite useful, is the following: * Friedrich Steimann "The paradoxical success of aspect-oriented programming" http://onward-conference.org/files/steimannessay.pdf Although not specifically related to Haskell or functional programming, it discusses an apparent paradox in a different programming paradigm, which could be useful when discussing functional paradigm-related issues pertaining to Haskell. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From duncan at well-typed.com Mon Mar 2 10:54:44 2009 From: duncan at well-typed.com (Duncan Coutts) Date: Mon Mar 2 10:43:49 2009 Subject: [Haskell] ANNOUNCE: The Industrial Haskell Group Message-ID: <1236009284.7915.222.camel@localhost> We are pleased to announce the creation of the Industrial Haskell Group (IHG). The IHG is an organisation to support the needs of commercial users of the Haskell programming language. For more information, please see http://industry.haskell.org/ Currently, the main activity of the IHG is a collaborative development scheme, in which multiple companies fund work on the Haskell development platform to their mutual benefit. The scheme has started with three partners of the IHG, including Galois and Amgen. More details are available at http://industry.haskell.org/collab If your company is interested in joining then please e-mail info@industry.haskell.org -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From kfisher at research.att.com Mon Mar 2 13:09:16 2009 From: kfisher at research.att.com (Kathleen Fisher) Date: Mon Mar 2 12:58:10 2009 Subject: [Haskell] CFP: Submit a talk proposal to CUFP References: Message-ID: <51E97E53-2A09-4A18-AEB5-0AEF97F2DF95@research.att.com> Hi all, This year CUFP will be held in Edinburgh, Scotland on 4 September. Bryan O'Sullivan, co-author of Real World Haskell, will deliver the keynote presentation, but we're now seeking proposals for regular presentations to complete the program. As you know, CUFP is the place to go to discuss real-world applications of functional programming and to meet the people involved. If you've got something interesting to say, please consider proposing a presentation. The complete call for presentations is below. Kind regards Kathleen Fisher (CUFP 2009 program committee member) Commercial Users of Functional Programming Workshop (CUFP) 2009 Functional Programming As a Means, Not an End Call for Presentations Sponsored by SIGPLAN Co-located with ICFP 2009 Edinburgh, Scotland, 4 September 2009 __________________________________________________________ Presentation proposals due 15 May 2009 http://cufp.galois.com/2009/call.html __________________________________________________________ Functional languages have been under academic development for over 25 years, and remain fertile ground for programming language research. Recently, however, developers in industrial, governmental, and open-source projects have begun to use functional programming successfully in practical applications. In these settings, functional programming has often provided dramatic leverage, including whole new ways of thinking about the original problem. The goal of the CUFP workshop is to act as a voice for these users of functional programming. The workshop supports the increasing viability of functional programming in the commercial, governmental, and open-source space by providing a forum for professionals to share their experiences and ideas, whether those ideas are related to business, management, or engineering. The workshop is also designed to enable the formation and reinforcement of relationships that further the commercial use of functional programming. Providing user feedback to language designers and implementors is not a primary goal of the workshop, though it will be welcome if it occurs. Speaking at CUFP If you use functional programming as a means, rather than as an end, we invite you to offer to give a talk at the workshop. Alternatively, if you know someone who would give a good talk, please nominate them! Talks are typically 25 minutes long, but can be shorter. They aim to inform participants about how functional programming played out in real-world applications, focusing especially on the re-usable lessons learned, or insights gained. Your talk does not need to be highly technical; for this audience, reflections on the commercial, management, or software engineering aspects are, if anything, more important. You do not need to submit a paper! If you are interested in offering a talk, or nominating someone to do so, send an e-mail to francesco(at)erlang-consulting(dot)com or jim(dot)d(dot)grundy(at)intel(dot)com by 15 May 2009 with a short description of what you'd like to talk about or what you think your nominee should give a talk about. Such descriptions should be about one page long. Program Plans CUFP 2009 will last a full day and feature a keynote presentation from Bryan O'Sullivan, co-author of Real World Haskell. The program will also include a mix of presentations and discussion sessions. Topics will range over a wide area, including: * Case studies of successful and unsuccessful uses of functional programming; * Business opportunities and risks from using functional languages; * Enablers for functional language use in a commercial setting; * Barriers to the adoption of functional languages, and * Mitigation strategies for overcoming limitations of functional programming. There will be no published proceedings, as the meeting is intended to be more a discussion forum than a technical interchange. This will be the sixth CUFP, for more information - including reports from attendees of previous events and video of recent talks - see the workshop web site: http://cufp.galois.com/ __________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090302/7df02cd8/attachment-0001.htm From leather at cs.uu.nl Tue Mar 3 06:57:05 2009 From: leather at cs.uu.nl (Sean Leather) Date: Tue Mar 3 06:45:49 2009 Subject: [Haskell] ANNOUNCE: Extensible and Modular Generics for the Masses: emgm-0.3 Message-ID: <3c6288ab0903030357y561cf9eei7c54d2b402192dde@mail.gmail.com> ============================================== Extensible and Modular Generics for the Masses ============================================== Extensible and Modular Generics for the Masses (EMGM) is a library for generic programming in Haskell using type classes and a sum-of-products view. ------- Updates ------- emgm-0.3 is the third major release, and it arrives a little over a month after emgm-0.2. Deriving is now greatly improved! Due to recent reports from users, we realized the current implementation just wasn't going to cut it. EMGM already supports a wide range of datatypes, so why not make the deriving code support just as many. Hopefully, it works well for you. Please let us know if your datatype is not supported. There are several new functions in the EMGM family. These include: cast (a type-safe, configurable, generic cast) and everywhere and everywhere' (functions similar to those of the same name in SYB that apply a transformation everywhere a certain type is found). ------- Changes ------- Changes from emgm-0.2 include: *? Improved deriving can now handle datatype collections like this one: ? http://www.haskell.org/pipermail/generics/2009-February/000429.html *? cast function > cast :: Rep (Map a) b => a -> b *? everywhere and everywhere' > everywhere :: Rep (Everywhere a) b => (a -> a) -> b -> b > everywhere' :: Rep (Everywhere' a) b => (a -> a) -> b -> b They both perform transformations on a-values in a b-value. The former does them bottom-up, the latter top-down. The names come from similar functions in SYB that use rank-2 types. Note the difference. > everywhere :: (forall a. Data a => a -> a) -> forall a. Data a => a -> a > everywhere' :: (forall a. Data a => a -> a) -> forall a. Data a => a -> a ------------ Known Issues ------------ Due to a problem with the template-haskell package and Cabal, you cannot cabal-install the emgm package with GHC 6.8. However, take heart! EMGM works very well with GHC 6.8. You merely have to download the tar.gz package from Hackage yourself, build it, and install it. Since it doesn't require any dependencies beyond what comes with GHC, installation is a breeze! ------------------- General Information ------------------- Visit the home page: ?http://www.cs.uu.nl/wiki/GenericProgramming/EMGM ---------------- General Features ---------------- The primary features of EMGM include: * ?Datatype-generic programming using sum-of-product views * ?Large collection of ready-to-use generic functions * ?Included support for standard datatypes: lists, Maybe, tuples * ?Easy to add support for new datatypes * ?Type classes make writing new functions straightforward in a structurally inductive style * ?Generic functions are extensible with ad-hoc cases for arbitrary datatypes * ?Good performance of generic functions The features of this distribution include: * ?The API is thoroughly documented with Haddock * ?Fully tested with QuickCheck and HUnit * ?Program coverage ensures that all useful code has been touched by tests * ?Tested on both Mac and Windows systems ------------ Requirements ------------ EMGM has the following requirements: * ?GHC 6.8.1 - It has been tested with versions 6.8.3 and 6.10.1 * ?Cabal library 1.2.1 - It has been tested with versions 1.2.4.0 and 1.6.0.1. ----------------- Download & Source ----------------- Use caball-install: ?cabal install emgm Get the package: ?http://hackage.haskell.org/cgi-bin/hackage-scripts/package/emgm Check out the current source with Subversion: ?svn checkout https://svn.cs.uu.nl:12443/repos/dgp-haskell/EMGM/trunk Or view it online: ? https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/trunk/ -------- Examples -------- Check out the examples: ?https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/trunk/examples/ -------------- Bugs & Support -------------- Report issues or request features: ? http://code.google.com/p/emgm/issues/list Discuss EMGM with the authors, maintainers, and other interested persons: ?http://www.haskell.org/mailman/listinfo/generics ------- Credits ------- The research for EMGM originated with Ralf Hinze. It was extended with work by Bruno Oliveira and Andres L?h. More details of the library functionality were explored by Alexey Rodriguez. We are very grateful to all of these people for the foundation on which this library was built. The current authors and maintainers of EMGM are: * ?Sean Leather * ?Jos? Pedro Magalh?es * ?Alexey Rodriguez * ?Andres L?h From matt at mattelder.org Wed Mar 4 20:29:39 2009 From: matt at mattelder.org (Matthew Elder) Date: Wed Mar 4 20:18:21 2009 Subject: [Haskell] ANN: Happstack 0.2 Released Message-ID: <987d172d0903041729m3d5d475dha3d8a08f18523377@mail.gmail.com> Happstack 0.2 has been released; it is available on Hackage. A lot of community effort has gone into it! For details, please see this post: http://blog.happstack.com/2009/03/04/happstack-02-released Regards, Matthew Elder -- Need somewhere to put your code? http://patch-tag.com Want to build a webapp? http://happstack.com From oleg at okmij.org Wed Mar 4 21:12:20 2009 From: oleg at okmij.org (oleg@okmij.org) Date: Wed Mar 4 21:03:14 2009 Subject: [Haskell] Lazy IO breaks purity Message-ID: <20090305021220.7FC65AB11@Adric.metnet.fnmoc.navy.mil> We demonstrate how lazy IO breaks referential transparency. A pure function of the type Int->Int->Int gives different integers depending on the order of evaluation of its arguments. Our Haskell98 code uses nothing but the standard input. We conclude that extolling the purity of Haskell and advertising lazy IO is inconsistent. Henning Thielemann wrote on Haskell-Cafe: > Say I have a chain of functions: read a file, ... write that to a file, > all of these functions are written in a lazy way, which is currently > considered good style Lazy IO should not be considered good style. One of the common definitions of purity is that pure expressions should evaluate to the same results regardless of evaluation order, or that equals can be substituted for equals. If an expression of the type Int evaluates to 1, we should be able to replace every occurrence of the expression with 1 without changing the results and other observables. The expression (read s) where s is the result of the (hGetContents h1) action has the pure type, e.g., Int. Yet its evaluation does more than just producing an integer: it may also close a file associated with the handle h1. Closing the file has an observable effect: the file descriptor, which is a scarce resource, is freed. Some OS lock the open file, or prevent operations such as renaming and deletion on the open file. A file system whose file is open cannot be unmounted. Suppose I use an Haskell application such as an editor to process data from a removable drive. I mount the drive, tell the application the file name. The (still running) application finished with the file and displayed the result. And yet I can't unplug the removable drive, because it turns out that the final result was produced without needing to read all the data from the file, and the file remains unclosed. Some people say: the programmer should have used seq. That is the admission of guilt! An expression (read s)::Int that evaluates to 1 is equal to 1. So, one should be able substitute (read s) with 1. If the result of evaluating 1 turns out not needed for the final outcome, then not evaluating (read s) should not affect the outcome. And yet it does. One uses seq to force evaluation of an expression even if the result may be unused. Thus the expression of a pure type has *side-effect*. The advice about using seq reminds me of advice given to C programmers that they should not free a malloc'ed pointer twice, dereference a zero pointer and write past the boundary of an array. If lazy IO is considered good style given the proper use of seq, then C should be considered safe given the proper use of pointers and arrays. Side affects like closing a file are observable in the external world. A program may observe these effects, in an IO monad. One can argue there are no guarantees at all about what happens in the IO monad. Can side-effects of lazy IO be observable in _pure_ Haskell code, in functions with pure type? Yes, they can. The examples are depressingly easy to write, once one realizes that reading does have side effects, POSIX provides for file descriptor aliasing, and sharing becomes observable with side effects. Here is a simple Haskell98 code. > {- Haskell98! -} > > module Main where > > import System.IO > import System.Posix.IO (fdToHandle, stdInput) > > -- f1 and f2 are both pure functions, with the pure type. > -- Both compute the result of the subtraction e1 - e2. > -- The only difference between them is the sequence of > -- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1 > -- For really pure functions, that difference should not be observable > > f1, f2:: Int -> Int -> Int > > f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2 > f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2 > > read_int s = read . head . words $ s > > main = do > let h1 = stdin > h2 <- fdToHandle stdInput > s1 <- hGetContents h1 > s2 <- hGetContents h2 > print $ f1 (read_int s1) (read_int s2) > -- print $ f2 (read_int s1) (read_int s2) One can compile it with GHC (I used 6.8.2, with and without -O2) and run like this ~> /tmp/a.out 1 2 -1 That is, we run the program and type 1 and 2 as the inputs. The program prints out the result, -1. If we comment out the line "print $ f1 (read_int s1) (read_int s2)" and uncomment out the last line the transcript looks like this ~> /tmp/a.out 1 2 1 Running the code with Hugs exhibits the same behavior. Thus a pure function (-) of the pure type gives different results depending on the order of evaluating its arguments. Is 1 = -1? From jonathanccast at fastmail.fm Wed Mar 4 21:22:06 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Mar 4 21:10:42 2009 Subject: [Haskell] Lazy IO breaks purity In-Reply-To: <20090305021220.7FC65AB11@Adric.metnet.fnmoc.navy.mil> References: <20090305021220.7FC65AB11@Adric.metnet.fnmoc.navy.mil> Message-ID: <1236219726.6239.1.camel@jonathans-macbook> On Wed, 2009-03-04 at 18:12 -0800, oleg@okmij.org wrote: > > We demonstrate how lazy IO breaks referential transparency. A pure > function of the type Int->Int->Int gives different integers depending > on the order of evaluation of its arguments. Our Haskell98 code uses > nothing but the standard input. We conclude that extolling the purity > of Haskell and advertising lazy IO is inconsistent. > > Henning Thielemann wrote on Haskell-Cafe: > > Say I have a chain of functions: read a file, ... write that to a file, > > all of these functions are written in a lazy way, which is currently > > considered good style > > Lazy IO should not be considered good style. One of the common > definitions of purity is that pure expressions should evaluate to the > same results regardless of evaluation order, or that equals can be > substituted for equals. If an expression of the type Int evaluates to > 1, we should be able to replace every occurrence of the expression with > 1 without changing the results and other observables. > > The expression (read s) where s is the result of the (hGetContents h1) > action has the pure type, e.g., Int. Yet its evaluation does more than > just producing an integer: it may also close a file associated with > the handle h1. Closing the file has an observable effect: the file > descriptor, which is a scarce resource, is freed. Some OS lock the > open file, or prevent operations such as renaming and deletion on the > open file. A file system whose file is open cannot be > unmounted. Suppose I use an Haskell application such as an editor to > process data from a removable drive. I mount the drive, tell the > application the file name. The (still running) application finished > with the file and displayed the result. And yet I can't unplug the > removable drive, because it turns out that the final result was > produced without needing to read all the data from the file, and the > file remains unclosed. > > Some people say: the programmer should have used seq. That is the > admission of guilt! An expression (read s)::Int that evaluates to 1 is > equal to 1. So, one should be able substitute (read s) with 1. If the > result of evaluating 1 turns out not needed for the final outcome, > then not evaluating (read s) should not affect the outcome. And yet it > does. One uses seq to force evaluation of an expression even if the > result may be unused. Thus the expression of a pure type > has *side-effect*. > > The advice about using seq reminds me of advice given to C programmers > that they should not free a malloc'ed pointer twice, dereference a > zero pointer and write past the boundary of an array. If lazy IO is > considered good style given the proper use of seq, then C should be > considered safe given the proper use of pointers and arrays. > > Side affects like closing a file are observable in the external > world. A program may observe these effects, in an IO monad. One can > argue there are no guarantees at all about what happens in the IO > monad. Can side-effects of lazy IO be observable in _pure_ Haskell > code, in functions with pure type? Yes, they can. The examples are > depressingly easy to write, once one realizes that reading does have > side effects, POSIX provides for file descriptor aliasing, and sharing > becomes observable with side effects. Here is a simple Haskell98 code. > > > > {- Haskell98! -} > > > > module Main where > > > > import System.IO > > import System.Posix.IO (fdToHandle, stdInput) > > > > -- f1 and f2 are both pure functions, with the pure type. > > -- Both compute the result of the subtraction e1 - e2. > > -- The only difference between them is the sequence of > > -- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1 > > -- For really pure functions, that difference should not be observable > > > > f1, f2:: Int -> Int -> Int > > > > f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2 > > f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2 > > > > read_int s = read . head . words $ s > > > > main = do > > let h1 = stdin > > h2 <- fdToHandle stdInput > > s1 <- hGetContents h1 > > s2 <- hGetContents h2 > > print $ f1 (read_int s1) (read_int s2) > > -- print $ f2 (read_int s1) (read_int s2) > > > One can compile it with GHC (I used 6.8.2, with and without -O2) and > run like this > ~> /tmp/a.out > 1 > 2 > -1 > That is, we run the program and type 1 and 2 as the inputs. The > program prints out the result, -1. If we comment out the line > "print $ f1 (read_int s1) (read_int s2)" and uncomment out the last > line the transcript looks like this > ~> /tmp/a.out > 1 > 2 > 1 > > Running the code with Hugs exhibits the same behavior. Thus a pure > function (-) of the pure type gives different results depending on the > order of evaluating its arguments. > > Is 1 = -1? Lazy IO *as implemented (originally) in GHC* (and copied into the Haskell standard) breaks referential transparency.[1] Clean's object IO system, I believe, would not have this problem. Nor would a well-designed Haskell IO system. jcc From jonathanccast at fastmail.fm Wed Mar 4 21:27:43 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Mar 4 21:16:34 2009 Subject: [Haskell] Lazy IO breaks purity In-Reply-To: <1236219726.6239.1.camel@jonathans-macbook> References: <20090305021220.7FC65AB11@Adric.metnet.fnmoc.navy.mil> <1236219726.6239.1.camel@jonathans-macbook> Message-ID: <1236220063.6239.3.camel@jonathans-macbook> On Wed, 2009-03-04 at 18:22 -0800, Jonathan Cast wrote: > On Wed, 2009-03-04 at 18:12 -0800, oleg@okmij.org wrote: > > > > We demonstrate how lazy IO breaks referential transparency. A pure > > function of the type Int->Int->Int gives different integers depending > > on the order of evaluation of its arguments. Our Haskell98 code uses > > nothing but the standard input. We conclude that extolling the purity > > of Haskell and advertising lazy IO is inconsistent. > ... > > Running the code with Hugs exhibits the same behavior. Thus a pure > > function (-) of the pure type gives different results depending on the > > order of evaluating its arguments. > > > > Is 1 = -1? > > Lazy IO *as implemented (originally) in GHC* (and copied into the > Haskell standard) breaks referential transparency.[1] Clean's object IO > system, I believe, would not have this problem. Nor would a > well-designed Haskell IO system. jcc [1] Oops, ignore this reference. I decided against saying what I was going to here. From dan.doel at gmail.com Wed Mar 4 22:04:32 2009 From: dan.doel at gmail.com (Dan Doel) Date: Wed Mar 4 21:53:10 2009 Subject: [Haskell] Lazy IO breaks purity In-Reply-To: <20090305021220.7FC65AB11@Adric.metnet.fnmoc.navy.mil> References: <20090305021220.7FC65AB11@Adric.metnet.fnmoc.navy.mil> Message-ID: <200903042204.33487.dan.doel@gmail.com> On Wednesday 04 March 2009 9:12:20 pm oleg@okmij.org wrote: > We demonstrate how lazy IO breaks referential transparency. A pure > function of the type Int->Int->Int gives different integers depending > on the order of evaluation of its arguments. Our Haskell98 code uses > nothing but the standard input. We conclude that extolling the purity > of Haskell and advertising lazy IO is inconsistent. > > Henning Thielemann wrote on Haskell-Cafe: > > Say I have a chain of functions: read a file, ... write that to a file, > > all of these functions are written in a lazy way, which is currently > > considered good style > > Lazy IO should not be considered good style. One of the common > definitions of purity is that pure expressions should evaluate to the > same results regardless of evaluation order, or that equals can be > substituted for equals. If an expression of the type Int evaluates to > 1, we should be able to replace every occurrence of the expression with > 1 without changing the results and other observables. > > The expression (read s) where s is the result of the (hGetContents h1) > action has the pure type, e.g., Int. Yet its evaluation does more than > just producing an integer: it may also close a file associated with > the handle h1. Closing the file has an observable effect: the file > descriptor, which is a scarce resource, is freed. Some OS lock the > open file, or prevent operations such as renaming and deletion on the > open file. A file system whose file is open cannot be > unmounted. Suppose I use an Haskell application such as an editor to > process data from a removable drive. I mount the drive, tell the > application the file name. The (still running) application finished > with the file and displayed the result. And yet I can't unplug the > removable drive, because it turns out that the final result was > produced without needing to read all the data from the file, and the > file remains unclosed. > > Some people say: the programmer should have used seq. That is the > admission of guilt! An expression (read s)::Int that evaluates to 1 is > equal to 1. So, one should be able substitute (read s) with 1. If the > result of evaluating 1 turns out not needed for the final outcome, > then not evaluating (read s) should not affect the outcome. And yet it > does. One uses seq to force evaluation of an expression even if the > result may be unused. Thus the expression of a pure type > has *side-effect*. > > The advice about using seq reminds me of advice given to C programmers > that they should not free a malloc'ed pointer twice, dereference a > zero pointer and write past the boundary of an array. If lazy IO is > considered good style given the proper use of seq, then C should be > considered safe given the proper use of pointers and arrays. > > Side affects like closing a file are observable in the external > world. A program may observe these effects, in an IO monad. One can > argue there are no guarantees at all about what happens in the IO > monad. Can side-effects of lazy IO be observable in _pure_ Haskell > code, in functions with pure type? Yes, they can. The examples are > depressingly easy to write, once one realizes that reading does have > side effects, POSIX provides for file descriptor aliasing, and sharing > becomes observable with side effects. Here is a simple Haskell98 code. > > > {- Haskell98! -} > > > > module Main where > > > > import System.IO > > import System.Posix.IO (fdToHandle, stdInput) > > > > -- f1 and f2 are both pure functions, with the pure type. > > -- Both compute the result of the subtraction e1 - e2. > > -- The only difference between them is the sequence of > > -- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1 > > -- For really pure functions, that difference should not be observable > > > > f1, f2:: Int -> Int -> Int > > > > f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2 > > f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2 > > > > read_int s = read . head . words $ s > > > > main = do > > let h1 = stdin > > h2 <- fdToHandle stdInput > > s1 <- hGetContents h1 > > s2 <- hGetContents h2 > > print $ f1 (read_int s1) (read_int s2) > > -- print $ f2 (read_int s1) (read_int s2) > > One can compile it with GHC (I used 6.8.2, with and without -O2) and > run like this > ~> /tmp/a.out > 1 > 2 > -1 > That is, we run the program and type 1 and 2 as the inputs. The > program prints out the result, -1. If we comment out the line > "print $ f1 (read_int s1) (read_int s2)" and uncomment out the last > line the transcript looks like this > ~> /tmp/a.out > 1 > 2 > 1 > > Running the code with Hugs exhibits the same behavior. Thus a pure > function (-) of the pure type gives different results depending on the > order of evaluating its arguments. > > Is 1 = -1? This does not conclusively demonstrate a violation of referential transparency. One can still consign the impurity to the IO monad. One just needs to specify that when hGetContents is called twice (or more times) on the standard input in the way you've done, what happens is that the input gets arbitrarily split between the two character streams in some way. It just so happens that when the program is compiled with f1, the split: s1 = "1\n..." s2 = "2\n..." is chosen, while when when compiled with f2, s1 = "2\n..." s2 = "1\n..." always happens to be chosen. So the difference can be modeled by IO making arbitrary, nondeterministic decisions that incidentally coincide with the evaluation order of things in the program. This is perhaps not very satisfying, and makes the semantics of IO very strange (IO actions can essentially look into the future), but it means referential transparency isn't broken. Note, for instance, that if you change the program to print the results of both f1 and f2, they will always agree, even though the order in which you print them will change which value they agree upon. -- Dan From lennart at augustsson.net Thu Mar 5 03:14:20 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Mar 5 03:02:56 2009 Subject: [Haskell] Lazy IO breaks purity In-Reply-To: <20090305021220.7FC65AB11@Adric.metnet.fnmoc.navy.mil> References: <20090305021220.7FC65AB11@Adric.metnet.fnmoc.navy.mil> Message-ID: I don't see any breaking of referential transparence in your code. Every time you do an IO operation the result is basically non-deterministic since you are talking to the outside world. You're assuming the IO has some kind of semantics that Haskell makes no promises about. I'm not saying that this isn't a problem, because it is. But it doesn't break referential transparency, it just makes the semantics of IO even more complicated. (I don't have a formal proof that unsafeInterleaveIO cannot break RT, but I've not seen an example where it does yet.) -- Lennart On Thu, Mar 5, 2009 at 2:12 AM, wrote: > > > We demonstrate how lazy IO breaks referential transparency. ?A pure > function of the type Int->Int->Int gives different integers depending > on the order of evaluation of its arguments. Our Haskell98 code uses > nothing but the standard input. ?We conclude that extolling the purity > of Haskell and advertising lazy IO is inconsistent. > > Henning Thielemann wrote on Haskell-Cafe: >> Say I have a chain of functions: read a file, ... write that to a file, >> all of these functions are written in a lazy way, which is currently >> considered good style > > Lazy IO should not be considered good style. One of the common > definitions of purity is that pure expressions should evaluate to the > same results regardless of evaluation order, or that equals can be > substituted for equals. If an expression of the type Int evaluates to > 1, we should be able to replace every occurrence of the expression with > 1 without changing the results and other observables. > > The expression (read s) where s is the result of the (hGetContents h1) > action has the pure type, e.g., Int. Yet its evaluation does more than > just producing an integer: it may also close a file associated with > the handle h1. Closing the file has an observable effect: the file > descriptor, which is a scarce resource, is freed. Some OS lock the > open file, or prevent operations such as renaming and deletion on the > open file. A file system whose file is open cannot be > unmounted. Suppose I use an Haskell application such as an editor to > process data from a removable drive. I mount the drive, tell the > application the file name. The (still running) application finished > with the file and displayed the result. And yet I can't unplug the > removable drive, because it turns out that the final result was > produced without needing to read all the data from the file, and the > file remains unclosed. > > Some people say: the programmer should have used seq. That is the > admission of guilt! An expression (read s)::Int that evaluates to 1 is > equal to 1. So, one should be able substitute (read s) with 1. If the > result of evaluating 1 turns out not needed for the final outcome, > then not evaluating (read s) should not affect the outcome. And yet it > does. One uses seq to force evaluation of an expression even if the > result may be unused. Thus the expression of a pure type > has *side-effect*. > > The advice about using seq reminds me of advice given to C programmers > that they should not free a malloc'ed pointer twice, dereference a > zero pointer and write past the boundary of an array. If lazy IO is > considered good style given the proper use of seq, then C should be > considered safe given the proper use of pointers and arrays. > > Side affects like closing a file are observable in the external > world. A program may observe these effects, in an IO monad. One can > argue there are no guarantees at all about what happens in the IO > monad. Can side-effects of lazy IO be observable in _pure_ Haskell > code, in functions with pure type? Yes, they can. The examples are > depressingly easy to write, once one realizes that reading does have > side effects, POSIX provides for file descriptor aliasing, and sharing > becomes observable with side effects. Here is a simple Haskell98 code. > > >> {- Haskell98! -} >> >> module Main where >> >> import System.IO >> import System.Posix.IO (fdToHandle, stdInput) >> >> -- f1 and f2 are both pure functions, with the pure type. >> -- Both compute the result of the subtraction e1 - e2. >> -- The only difference between them is the sequence of >> -- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1 >> -- For really pure functions, that difference should not be observable >> >> f1, f2:: Int -> Int -> Int >> >> f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2 >> f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2 >> >> read_int s = read . head . words $ s >> >> main = do >> ? ? ? ?let h1 = stdin >> ? ? ? ?h2 <- fdToHandle stdInput >> ? ? ? ?s1 <- hGetContents h1 >> ? ? ? ?s2 <- hGetContents h2 >> ? ? ? ?print $ f1 (read_int s1) (read_int s2) >> ? ? ? ?-- print $ f2 (read_int s1) (read_int s2) > > > One can compile it with GHC (I used 6.8.2, with and without -O2) and > run like this > ? ~> /tmp/a.out > ? 1 > ? 2 > ? -1 > That is, we run the program and type 1 and 2 as the inputs. The > program prints out the result, -1. If we comment out the line > "print $ f1 (read_int s1) (read_int s2)" and uncomment out the last > line the transcript looks like this > ? ~> /tmp/a.out > ? 1 > ? 2 > ? 1 > > Running the code with Hugs exhibits the same behavior. Thus a pure > function (-) of the pure type gives different results depending on the > order of evaluating its arguments. > > ? ? ? ?Is 1 = -1? > > > > > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From noteed at gmail.com Thu Mar 5 03:36:16 2009 From: noteed at gmail.com (minh thu) Date: Thu Mar 5 03:24:50 2009 Subject: [Haskell] Lazy IO breaks purity In-Reply-To: References: <20090305021220.7FC65AB11@Adric.metnet.fnmoc.navy.mil> Message-ID: <40a414c20903050036g571ebd3age9eeca5bc98e354@mail.gmail.com> Hi, It seems to me that basically, a run of Oleg's code is :: IO Int, not Int, so there is little sense to talk about referential transparencies by comparing the results of two runs. It would have sense by making the comparison directly in a single run, inside the code (using a pure compare function). Cheers, Thu 2009/3/5 Lennart Augustsson : > I don't see any breaking of referential transparence in your code. > Every time you do an IO operation the result is basically > non-deterministic since you are talking to the outside world. > You're assuming the IO has some kind of semantics that Haskell makes > no promises about. > > I'm not saying that this isn't a problem, because it is. > But it doesn't break referential transparency, it just makes the > semantics of IO even more complicated. > > (I don't have a formal proof that unsafeInterleaveIO cannot break RT, > but I've not seen an example where it does yet.) > > -- Lennart > > On Thu, Mar 5, 2009 at 2:12 AM, wrote: >> >> >> We demonstrate how lazy IO breaks referential transparency. A pure >> function of the type Int->Int->Int gives different integers depending >> on the order of evaluation of its arguments. Our Haskell98 code uses >> nothing but the standard input. We conclude that extolling the purity >> of Haskell and advertising lazy IO is inconsistent. >> >> Henning Thielemann wrote on Haskell-Cafe: >>> Say I have a chain of functions: read a file, ... write that to a file, >>> all of these functions are written in a lazy way, which is currently >>> considered good style >> >> Lazy IO should not be considered good style. One of the common >> definitions of purity is that pure expressions should evaluate to the >> same results regardless of evaluation order, or that equals can be >> substituted for equals. If an expression of the type Int evaluates to >> 1, we should be able to replace every occurrence of the expression with >> 1 without changing the results and other observables. >> >> The expression (read s) where s is the result of the (hGetContents h1) >> action has the pure type, e.g., Int. Yet its evaluation does more than >> just producing an integer: it may also close a file associated with >> the handle h1. Closing the file has an observable effect: the file >> descriptor, which is a scarce resource, is freed. Some OS lock the >> open file, or prevent operations such as renaming and deletion on the >> open file. A file system whose file is open cannot be >> unmounted. Suppose I use an Haskell application such as an editor to >> process data from a removable drive. I mount the drive, tell the >> application the file name. The (still running) application finished >> with the file and displayed the result. And yet I can't unplug the >> removable drive, because it turns out that the final result was >> produced without needing to read all the data from the file, and the >> file remains unclosed. >> >> Some people say: the programmer should have used seq. That is the >> admission of guilt! An expression (read s)::Int that evaluates to 1 is >> equal to 1. So, one should be able substitute (read s) with 1. If the >> result of evaluating 1 turns out not needed for the final outcome, >> then not evaluating (read s) should not affect the outcome. And yet it >> does. One uses seq to force evaluation of an expression even if the >> result may be unused. Thus the expression of a pure type >> has *side-effect*. >> >> The advice about using seq reminds me of advice given to C programmers >> that they should not free a malloc'ed pointer twice, dereference a >> zero pointer and write past the boundary of an array. If lazy IO is >> considered good style given the proper use of seq, then C should be >> considered safe given the proper use of pointers and arrays. >> >> Side affects like closing a file are observable in the external >> world. A program may observe these effects, in an IO monad. One can >> argue there are no guarantees at all about what happens in the IO >> monad. Can side-effects of lazy IO be observable in _pure_ Haskell >> code, in functions with pure type? Yes, they can. The examples are >> depressingly easy to write, once one realizes that reading does have >> side effects, POSIX provides for file descriptor aliasing, and sharing >> becomes observable with side effects. Here is a simple Haskell98 code. >> >> >>> {- Haskell98! -} >>> >>> module Main where >>> >>> import System.IO >>> import System.Posix.IO (fdToHandle, stdInput) >>> >>> -- f1 and f2 are both pure functions, with the pure type. >>> -- Both compute the result of the subtraction e1 - e2. >>> -- The only difference between them is the sequence of >>> -- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1 >>> -- For really pure functions, that difference should not be observable >>> >>> f1, f2:: Int -> Int -> Int >>> >>> f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2 >>> f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2 >>> >>> read_int s = read . head . words $ s >>> >>> main = do >>> let h1 = stdin >>> h2 <- fdToHandle stdInput >>> s1 <- hGetContents h1 >>> s2 <- hGetContents h2 >>> print $ f1 (read_int s1) (read_int s2) >>> -- print $ f2 (read_int s1) (read_int s2) >> >> >> One can compile it with GHC (I used 6.8.2, with and without -O2) and >> run like this >> ~> /tmp/a.out >> 1 >> 2 >> -1 >> That is, we run the program and type 1 and 2 as the inputs. The >> program prints out the result, -1. If we comment out the line >> "print $ f1 (read_int s1) (read_int s2)" and uncomment out the last >> line the transcript looks like this >> ~> /tmp/a.out >> 1 >> 2 >> 1 >> >> Running the code with Hugs exhibits the same behavior. Thus a pure >> function (-) of the pure type gives different results depending on the >> order of evaluating its arguments. >> >> Is 1 = -1? >> >> >> >> >> >> >> _______________________________________________ >> Haskell mailing list >> Haskell@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell >> > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From sebf at informatik.uni-kiel.de Thu Mar 5 07:35:03 2009 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Thu Mar 5 07:23:41 2009 Subject: [Haskell] ANN: pandoc 1.2 In-Reply-To: <20090301192139.GC26057@berkeley.edu> References: <20090301192139.GC26057@berkeley.edu> Message-ID: <6357D0E1-EC36-472F-9A49-6A6A38FF750C@informatik.uni-kiel.de> On Mar 1, 2009, at 8:21 PM, John MacFarlane wrote: > I'm pleased to announce the release of pandoc version 1.2 > (uploaded today to HackageDB). > > The most significant new feature is support for literate Haskell. That is a very useful feature. It let's us mash-up pandoc and lhs2TeX to create nicely formatted PDFs from literate Haskell formatted as markdown: pandoc --to=latex+lhs --custom-header=header.tex program.lhs |\ lhs2TeX --output=program && pdflatex program The file header.tex must contain an appropriate document style and the line %include lhs2TeX.fmt A slight drawback is that code written indented or between ~~~ (and hence not meant to be executed) is converted to a `verbatim` environment. As a consequence, lhs2TeX does not use the same formatting as in code blocks. To fix this we can insert this in the pipe: sed s/\\begin{verbatim}/\\begin{spec}/ |\ sed s/\\end{verbatim}/\\end{spec}/ but of course this is hack, that does not work, if we want to write the replaced strings somewhere in our document.. Unfortunately, I did not manage to use the citeproc extension to get references in the text and a bibliography at the end of the latex file, thus need to resort to \cite{...} in the source code and bibtex. Nevertheless, a very useful tool! Cheers, Sebastian From oleg at okmij.org Thu Mar 5 23:11:21 2009 From: oleg at okmij.org (oleg@okmij.org) Date: Thu Mar 5 23:02:15 2009 Subject: [Haskell] Definitions of purity and Lazy IO Message-ID: <20090306041121.DE8EDABBB@Adric.metnet.fnmoc.navy.mil> As Amr Sabry aptly observed more than a decade ago discussions of purity and referential transparency usually lead to confusion and disagreement. His JFP paper provided the needed rigor and argued that Haskell even _with regular file (stream) IO_ is pure. As was shown yesterday, with Lazy IO, Haskell is not pure. Before we discuss definitions, let us note the motivations. Suppose I have a Haskell program. As every single (compiled) Haskell program it has the main function, of the type IO a for some a. It must use IO, at least to print the final result, the observation of the program. Suppose the program contains the expression "e1 + e2" adding two integer expressions. Can I replace this expression with "e2 + e1" and be sure the observations of my program are unaffected? If one says that ``you should assume that every IO operation returns a random result'' then we have no ability to reason about any real Haskell program. We can't be sure of soundness of any compiler optimization. So, Haskell is far worse than C!? With C, Xavier Leroy has managed to create a provably correct optimizing compiler, and mechanically _prove_ the soundness of all optimizations. A C program, just like a Haskell program, must use IO at least to print the final result. We can never hope to build a provably correct compiler for Haskell? We cannot prove observational equivalences of any real Haskell program? Isn't that sad? The formal question is thus: are the following two expressions f1 and f2, of a *pure type* Int->Int->Int f1, f2:: Int -> Int -> Int f1 = \e1 e2 -> case (e1,e2) of (1,_) -> e1 - e2 (_,_) -> e1 - e2 f2 = \e1 e2 -> case (e1,e2) of (_,1) -> e1 - e2 (_,_) -> e1 - e2 equal? Before one invokes an equational theory or says that both these expressions are just integer subtraction, let me clarify the question: are f1 and f2 at least weakly observationally equivalent? That is, for any program context C[] such that C[f1] is well-typed, the program C[f2] must too be well-typed, and if one can observe the result of C[f1] and of C[f2], the two observations must be identical. The observation of a program may (and often does) involve side-effects and IO (more on it below). The message posted yesterday exhibited a context C[] that distinguishes f1 from f2. Thus, in presence of Lazy IO, any equational theory that equates f1 and f2 cannot be sound. I don't think one can design such a context C[] using the regular, eager file IO. Amr Sabry in a paper ``What is a Purely Functional Language?'' J. Functional Programming, 8(1), 1-22, Jan. 1998. http://www.cs.indiana.edu/~sabry/papers/purelyFunctional.ps proposed the definition of purity, see p 2 and Definition 4.7. The definition essentially states that call-by-name, call-by-value and call-by-need evaluation functions must be weakly equivalent. These evaluation functions map programs to observables. The part of evaluation dealing with observing the answers may have side effects! Sec 5.1 rigorously shows that lambda-calculus with global state and destructive mutation may be called pure functional, if effects are regarded as values and the program is written in what we now call a monadic style (whose idea was proposed by Reynolds back in 1981 when studying Idealized Algol). The end of Sec 5.1 remarks that IO can be treated that way -- and in fact, Appendix D of Haskell report 1.2 indeed had described such a semantics of IO: http://haskell.org/definition/haskell-report-1.2.ps.gz (the appendix starts on p. 139). Thanks to Paul Hudak for pointing this out three years ago. Thus Haskell even with IO may be called pure functional. With Lazy IO, it can no longer be called pure functional as different orders of evaluation of arguments of a function lead to different program observations. From jonathanccast at fastmail.fm Thu Mar 5 23:48:33 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Mar 5 23:37:08 2009 Subject: [Haskell] Definitions of purity and Lazy IO In-Reply-To: <20090306041121.DE8EDABBB@Adric.metnet.fnmoc.navy.mil> References: <20090306041121.DE8EDABBB@Adric.metnet.fnmoc.navy.mil> Message-ID: <1236314913.7500.35.camel@jonathans-macbook> On Thu, 2009-03-05 at 20:11 -0800, oleg@okmij.org wrote: > As Amr Sabry aptly observed more than a decade ago discussions of > purity and referential transparency usually lead to confusion and > disagreement. His JFP paper provided the needed rigor and argued that > Haskell even _with regular file (stream) IO_ is pure. As was shown > yesterday, with Lazy IO, Haskell is not pure. > > Before we discuss definitions, let us note the motivations. Suppose I > have a Haskell program. As every single (compiled) Haskell program it > has the main function, of the type IO a for some a. It must use IO, at > least to print the final result, the observation of the > program. Suppose the program contains the expression "e1 + e2" adding > two integer expressions. Can I replace this expression with "e2 + e1" > and be sure the observations of my program are unaffected? > > If one says that ``you should assume that every IO operation returns a > random result'' then we have no ability to reason about any > real Haskell. I think that `real' is a poor term to use in this context. In any case, we don't really need to assert that *any* IO action is non-deterministic; we just have to assert that: a) The result returned by unsafeInterleaveIO is non-deterministic, and b) The point in the execution thread when the side effects performed by unsafeInterleaveIO are inserted is non-deterministic. As for the first claim: we have *stronger* guarantees for unsafeInterleaveIO than for getStdRandom. As for the second claim: we have *stronger* guarantees for unsafeInterleavIO than for forkIO. I don't think it removes all possibility of reasoning about Haskell programs to say these things. You might want to stop hyper-ventilating. > We can't be sure of soundness of any compiler > optimization. Nope. *You* claim, without proof, that re-writing x `seq` y `seq` x - y to y `seq` x `seq` x - y is an un-sound optimization, for Haskell. *We* claim it is perfectly sound. Who is denying the soundness of Haskell optimization again? > So, Haskell is far worse than C!? With C, Xavier Leroy > has managed to create a provably correct optimizing compiler, and > mechanically _prove_ the soundness of all optimizations. And plenty of C programs have situations where the relative ordering of side effects is undefined. In fact, quite a few syntactically valid, well-typed, conforming C programs are declared `undefined' (and hence not *strictly* conforming) by the standard, because their meaning depends on the order of evaluation beyond the degree to which it is well-defined. So C is hardly `far [better]' than Haskell in this regard! > A C program, > just like a Haskell program, must use IO at least to print the > final result. We can never hope to build a provably correct compiler for > Haskell? We cannot prove observational equivalences of any real > Haskell program? Isn't that sad? > The formal question is thus: are the following two expressions f1 and f2, > of a *pure type* Int->Int->Int > > f1, f2:: Int -> Int -> Int > f1 = \e1 e2 -> case (e1,e2) of > (1,_) -> e1 - e2 > (_,_) -> e1 - e2 > > f2 = \e1 e2 -> case (e1,e2) of > (_,1) -> e1 - e2 > (_,_) -> e1 - e2 > > equal? Before one invokes an equational theory or says that both these > expressions are just integer subtraction, let me clarify the > question: are f1 and f2 at least weakly observationally equivalent? How weak? > That is, for any program context C[] such that C[f1] is well-typed, > the program C[f2] must too be well-typed, and if one can observe the > result of C[f1] and of C[f2], the two observations must be identical. Every time? For every context? What about the context do x <- getStdRandom random y <- getStdRandom random print $ [] x y ? By the standard above, f1 is not even observationally equivalent to *itself*. > The > observation of a program may (and often does) involve side-effects and > IO (more on it below). The message posted yesterday exhibited a context C[] that > distinguishes f1 from f2. Thus, in presence of Lazy IO, any equational > theory that equates f1 and f2 cannot be sound. I don't think one can > design such a context C[] using the regular, eager file IO. > > Amr Sabry in a paper ``What is a Purely Functional Language?'' > J. Functional Programming, 8(1), 1-22, Jan. 1998. > http://www.cs.indiana.edu/~sabry/papers/purelyFunctional.ps > > proposed the definition of purity, see p 2 and Definition 4.7. The > definition essentially states that call-by-name, call-by-value and > call-by-need evaluation functions must be weakly equivalent. How weakly? (False && undefined) gives different answers under call-by-name and call-by-value, but I don't think calling Haskell `unpure' because it exists is useful. > These > evaluation functions map programs to observables. The part of > evaluation dealing with observing the answers may have side effects! > Sec 5.1 rigorously shows that lambda-calculus with global state > and destructive mutation may be called pure functional, if > effects are regarded as values and the program is written in what we > now call a monadic style (whose idea was proposed by Reynolds back in > 1981 when studying Idealized Algol). The end of Sec 5.1 remarks that > IO can be treated that way -- and in fact, Appendix D of Haskell > report 1.2 indeed had described such a semantics of IO: > http://haskell.org/definition/haskell-report-1.2.ps.gz > (the appendix starts on p. 139). Thanks to Paul Hudak for pointing this > out three years ago. Ahah! Haskell 1.2 had lazy IO (readChan), no? > Thus Haskell even with IO may be called pure functional. With Lazy IO, For Lazy IO, read unsafeInterleaveIO. > it can no longer be called pure functional as different orders of > evaluation of arguments of a function lead to different program > observations. Maybe. Nothing says GHC *won't* re-write f1 into f2, or vice-versa; it just happens to be the case that when you tried it it didn't happen. jcc From DekuDekuplex at Yahoo.com Fri Mar 6 00:59:02 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Fri Mar 6 00:47:45 2009 Subject: [Haskell] (fwd) Haskell Career Opportunity Message-ID: <0qe1r451n0bag7hem4cujiqce36cebos61@4ax.com> James Wood, Senior Consultant of The Kaizen Partnership, has posted the following message on fa.haskell about a Haskell career opportunity, so I am forwarding it to here for your information: On Thu, 5 Mar 2009 07:00:57 -0800 (PST), in fa.haskell James Wood wrote: >Dear All > >I am a headhunter with a focus on tech developers predominantly in the >finance sector. Part of my focus is functional programmers especially >in Haskell, OCaml, F#. I am not sure if I am allowed to post this here >but I figured it might be relevant to some of you and so took a >chance. > >I'm currently working on a role for an Investment Bank which has >emerged unscathed from the economic turmoil and is actively looking >for highly advanced Haskell programmers. Ideally candidates will have >a MSc or PhD in Computer Science or Mathematics and will be very >comfortable programming in Haskell. The team is part of the front- >office quant analytics group and is using functional programming in >novel ways to solve some interesting problems both in both technology >and risk modelling. They are looking to add several more key hires >over the year. Finance experience is not necessary but can be >advantageous. Location can be flexible. > >There are only a few banks who have seriously invested in functional >programming and actually incorporate it as part of their >infrastructure. If anyone is interested in discussing this with me >feel free to give me a ring or email my work email, >jwood@kaizenpartnership.co.uk > >Thanks > >James > > >James Wood >Senior Consultant >The Kaizen Partnership > > +44 (0) 20 7710 0280 -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From noteed at gmail.com Fri Mar 6 03:29:23 2009 From: noteed at gmail.com (minh thu) Date: Fri Mar 6 03:17:55 2009 Subject: [Haskell] Definitions of purity and Lazy IO In-Reply-To: <20090306041121.DE8EDABBB@Adric.metnet.fnmoc.navy.mil> References: <20090306041121.DE8EDABBB@Adric.metnet.fnmoc.navy.mil> Message-ID: <40a414c20903060029n45d5d878k9af223739d103219@mail.gmail.com> 2009/3/6 : > > As Amr Sabry aptly observed more than a decade ago discussions of > purity and referential transparency usually lead to confusion and > disagreement. His JFP paper provided the needed rigor and argued that > Haskell even _with regular file (stream) IO_ is pure. As was shown > yesterday, with Lazy IO, Haskell is not pure. > > Before we discuss definitions, let us note the motivations. Suppose I > have a Haskell program. As every single (compiled) Haskell program it > has the main function, of the type IO a for some a. It must use IO, at > least to print the final result, the observation of the > program. Suppose the program contains the expression "e1 + e2" adding > two integer expressions. Can I replace this expression with "e2 + e1" > and be sure the observations of my program are unaffected? > > If one says that ``you should assume that every IO operation returns a > random result'' then we have no ability to reason about any > real Haskell program. We can't be sure of soundness of any compiler > optimization. So, Haskell is far worse than C!? With C, Xavier Leroy > has managed to create a provably correct optimizing compiler, and > mechanically _prove_ the soundness of all optimizations. A C program, > just like a Haskell program, must use IO at least to print the > final result. We can never hope to build a provably correct compiler for > Haskell? We cannot prove observational equivalences of any real > Haskell program? Isn't that sad? > > The formal question is thus: are the following two expressions f1 and f2, > of a *pure type* Int->Int->Int > > f1, f2:: Int -> Int -> Int > f1 = \e1 e2 -> case (e1,e2) of > (1,_) -> e1 - e2 > (_,_) -> e1 - e2 > > f2 = \e1 e2 -> case (e1,e2) of > (_,1) -> e1 - e2 > (_,_) -> e1 - e2 > > equal? Before one invokes an equational theory or says that both these > expressions are just integer subtraction, let me clarify the > question: are f1 and f2 at least weakly observationally equivalent? > That is, for any program context C[] such that C[f1] is well-typed, > the program C[f2] must too be well-typed, and if one can observe the > result of C[f1] and of C[f2], the two observations must be identical. The > observation of a program may (and often does) involve side-effects and > IO (more on it below). The message posted yesterday exhibited a context C[] that > distinguishes f1 from f2. Thus, in presence of Lazy IO, any equational > theory that equates f1 and f2 cannot be sound. I don't think one can > design such a context C[] using the regular, eager file IO. > [...] Thanks for clarifying, I see how I was wrong yesterday. I was to quick at pointing the use of IO instead of observing that the pure functions f1 and f2 have themself an effect. Thu From duncan.coutts at worc.ox.ac.uk Fri Mar 6 05:02:01 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Mar 6 04:50:38 2009 Subject: [Haskell] Definitions of purity and Lazy IO In-Reply-To: <20090306041121.DE8EDABBB@Adric.metnet.fnmoc.navy.mil> References: <20090306041121.DE8EDABBB@Adric.metnet.fnmoc.navy.mil> Message-ID: <1236333721.22402.261.camel@localhost> On Thu, 2009-03-05 at 20:11 -0800, oleg@okmij.org wrote: > > Before one invokes an equational theory or says that both these > expressions are just integer subtraction, let me clarify the > question: are f1 and f2 at least weakly observationally equivalent? > That is, for any program context C[] such that C[f1] is well-typed, > the program C[f2] must too be well-typed, and if one can observe the > result of C[f1] and of C[f2], the two observations must be identical. The > observation of a program may (and often does) involve side-effects and > IO (more on it below). The message posted yesterday exhibited a > context C[] that distinguishes f1 from f2. Thus, in presence of Lazy > IO, any equational theory that equates f1 and f2 cannot be sound. I > don't think one can design such a context C[] using the regular, eager > file IO. I'm not sure that observational equivalence on IO computations the right approach. For example it means we cannot explain imprecise exceptions. http://research.microsoft.com/en-us/um/people/simonpj/papers/imprecise-exn.htm With imprecise exceptions we define the meaning of a value that could return one of a number of exceptions to actually return the whole set (see Sections 3.4, 3.5 and 4 above). But on any particular run the representative member of that set of exceptions can be different. They give the example: do v1 <- getException ((1/0) + error "Urk") v2 <- getException ((1/0) + error "Urk") return (v1 == v2) The solution is that getException makes a non-deterministic choice each time. I expect that unsafeInterleaveIO can be explained in a similar way, via non-determinism in the choice of interleaving of events. Any final observations correspond to some particular interleaving, we just do not know which one it is going to be until we inspect the value. The semantics is that it can be any of them. Different runs of the program, different compiler transformations or evaluation orders can change which values we typically observe without breaking the semantics that it could be any of the possible values. This is somewhat stronger than the semantics of a random number generator in IO because not all interleavings are possible and some interleavings of effects do not interfere with each other. > Thus Haskell even with IO may be called pure functional. With Lazy IO, > it can no longer be called pure functional as different orders of > evaluation of arguments of a function lead to different program > observations. The same is true of imprecise exceptions and yet we do not seem to be worried about them destroying purity. Duncan From matthew.pocock at ncl.ac.uk Fri Mar 6 07:33:36 2009 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Fri Mar 6 07:22:08 2009 Subject: [Haskell] string type class Message-ID: <200903061233.36400.matthew.pocock@ncl.ac.uk> Hi, It seems every time I look at hackage there is yet another stringy datatype. For lots of apps, the particular stringy datatype you use matters for performance but not algorithmic reasons. Perhaps this is a good time for someone to propose a stringy class? Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090306/809578af/attachment.htm From g9ks157k at acme.softbase.org Fri Mar 6 11:13:43 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Mar 6 11:02:14 2009 Subject: [Haskell] string type class In-Reply-To: <200903061233.36400.matthew.pocock@ncl.ac.uk> References: <200903061233.36400.matthew.pocock@ncl.ac.uk> Message-ID: <200903061713.43573.g9ks157k@acme.softbase.org> Am Freitag, 6. M?rz 2009 13:33 schrieb Matthew Pocock: > Hi, > > It seems every time I look at hackage there is yet another stringy > datatype. For lots of apps, the particular stringy datatype you use matters > for performance but not algorithmic reasons. Perhaps this is a good time > for someone to propose a stringy class? > > Matthew There is already the class IsString which was introduced for overloaded string literals. However, the name is terrible. No other Haskell class I know of has an ?Is? at its beginning. Classes don?t name properties (IsNum, IsMonoid, Has?). Maybe you can also try to convince the masters of the IsString class to change the class name. My previous attempts through mailing list e-mails seemed to have no effect. :-( Best wishes, Wolfgang From noteed at gmail.com Fri Mar 6 11:16:41 2009 From: noteed at gmail.com (minh thu) Date: Fri Mar 6 11:05:12 2009 Subject: [Haskell] string type class In-Reply-To: <200903061713.43573.g9ks157k@acme.softbase.org> References: <200903061233.36400.matthew.pocock@ncl.ac.uk> <200903061713.43573.g9ks157k@acme.softbase.org> Message-ID: <40a414c20903060816q1eff8d2as5e36d80a825b86c1@mail.gmail.com> 2009/3/6 Wolfgang Jeltsch : > Am Freitag, 6. M?rz 2009 13:33 schrieb Matthew Pocock: >> Hi, >> >> It seems every time I look at hackage there is yet another stringy >> datatype. For lots of apps, the particular stringy datatype you use matters >> for performance but not algorithmic reasons. Perhaps this is a good time >> for someone to propose a stringy class? >> >> Matthew > > There is already the class IsString which was introduced for overloaded string > literals. > > However, the name is terrible. No other Haskell class I know of has an ?Is? at > its beginning. Classes don?t name properties (IsNum, IsMonoid, Has?). LLVM bindings use it a lot... Cheers, Thu From ekmett at gmail.com Fri Mar 6 11:28:40 2009 From: ekmett at gmail.com (Edward Kmett) Date: Fri Mar 6 11:17:09 2009 Subject: [Haskell] string type class In-Reply-To: <40a414c20903060816q1eff8d2as5e36d80a825b86c1@mail.gmail.com> References: <200903061233.36400.matthew.pocock@ncl.ac.uk> <200903061713.43573.g9ks157k@acme.softbase.org> <40a414c20903060816q1eff8d2as5e36d80a825b86c1@mail.gmail.com> Message-ID: <7fb8f82f0903060828n1c89ec44ncc8244dbab3f0e56@mail.gmail.com> I'd be more interested in a kitchen-sink "List" class. ByteString, ByteString.Lazy, Text, [a], and the pending Text.Lazy all support the basic operations of lists of a particular type. It'd be a fairly huge dictionary by the current API design of those however. Its just a reiteration of the classic "Collection" class example. The biggest problem is that it requires either MPTCs/fundeps or type aliases to make it work, which makes less progressive folks queasy about its inclusion as a standard library. On the other hand, if you're going that far, it'd be nice to factor out a superclass or two for things like lookup/insert functionality, so you can eliminate a major reason why Data.Map has to be imported qualified as well. -Edward Kmett On Fri, Mar 6, 2009 at 11:16 AM, minh thu wrote: > 2009/3/6 Wolfgang Jeltsch : > > Am Freitag, 6. M?rz 2009 13:33 schrieb Matthew Pocock: > >> Hi, > >> > >> It seems every time I look at hackage there is yet another stringy > >> datatype. For lots of apps, the particular stringy datatype you use > matters > >> for performance but not algorithmic reasons. Perhaps this is a good time > >> for someone to propose a stringy class? > >> > >> Matthew > > > > There is already the class IsString which was introduced for overloaded > string > > literals. > > > > However, the name is terrible. No other Haskell class I know of has an > ?Is? at > > its beginning. Classes don?t name properties (IsNum, IsMonoid, Has?). > > LLVM bindings use it a lot... > > Cheers, > Thu > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090306/44e26ed7/attachment.htm From g9ks157k at acme.softbase.org Fri Mar 6 12:05:48 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Mar 6 11:54:20 2009 Subject: [Haskell] string type class In-Reply-To: References: <200903061233.36400.matthew.pocock@ncl.ac.uk> <200903061713.43573.g9ks157k@acme.softbase.org> Message-ID: <200903061805.48991.g9ks157k@acme.softbase.org> Am Freitag, 6. M?rz 2009 17:31 schrieben Sie: > What name would you suggest? If we wouldn?t have to care about compatibility, I would name the class String and drop the type alias String. It?s hard to come up with a good name since String is already taken. However, things like StringLike, Stringy, Chars etc. are probable still better than IsString since they describe the things (values of instances of that class) instead of stating a property of them. Best wishes, Wolfgang From leather at cs.uu.nl Fri Mar 6 12:22:57 2009 From: leather at cs.uu.nl (Sean Leather) Date: Fri Mar 6 12:11:28 2009 Subject: [Haskell] string type class In-Reply-To: <7fb8f82f0903060828n1c89ec44ncc8244dbab3f0e56@mail.gmail.com> References: <200903061233.36400.matthew.pocock@ncl.ac.uk> <200903061713.43573.g9ks157k@acme.softbase.org> <40a414c20903060816q1eff8d2as5e36d80a825b86c1@mail.gmail.com> <7fb8f82f0903060828n1c89ec44ncc8244dbab3f0e56@mail.gmail.com> Message-ID: <3c6288ab0903060922y34b509dco49bdff8bbb7bdcff@mail.gmail.com> > I'd be more interested in a kitchen-sink "List" class. ByteString, > ByteString.Lazy, Text, [a], and the pending Text.Lazy all support the basic > operations of lists of a particular type. It'd be a fairly huge dictionary > by the current API design of those however. Its just a reiteration of the > classic "Collection" class example. > Like this? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ListLike Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090306/cac92144/attachment.htm From dave at zednenem.com Fri Mar 6 12:24:20 2009 From: dave at zednenem.com (David Menendez) Date: Fri Mar 6 12:12:50 2009 Subject: [Haskell] string type class In-Reply-To: <200903061805.48991.g9ks157k@acme.softbase.org> References: <200903061233.36400.matthew.pocock@ncl.ac.uk> <200903061713.43573.g9ks157k@acme.softbase.org> <200903061805.48991.g9ks157k@acme.softbase.org> Message-ID: <49a77b7a0903060924sae9bb49q7888344090e79ccb@mail.gmail.com> On Fri, Mar 6, 2009 at 12:05 PM, Wolfgang Jeltsch wrote: > Am Freitag, 6. M?rz 2009 17:31 schrieben Sie: >> What name would you suggest? > > If we wouldn?t have to care about compatibility, I would name the class String > and drop the type alias String. > > It?s hard to come up with a good name since String is already taken. However, > things like StringLike, Stringy, Chars etc. are probable still better than > IsString since they describe the things (values of instances of that class) > instead of stating a property of them. How about CharSequence? -- Dave Menendez From noteed at gmail.com Fri Mar 6 12:49:14 2009 From: noteed at gmail.com (minh thu) Date: Fri Mar 6 12:37:43 2009 Subject: [Haskell] string type class In-Reply-To: <49a77b7a0903060924sae9bb49q7888344090e79ccb@mail.gmail.com> References: <200903061233.36400.matthew.pocock@ncl.ac.uk> <200903061713.43573.g9ks157k@acme.softbase.org> <200903061805.48991.g9ks157k@acme.softbase.org> <49a77b7a0903060924sae9bb49q7888344090e79ccb@mail.gmail.com> Message-ID: <40a414c20903060949q6222057an8748dd76781700c7@mail.gmail.com> 2009/3/6 David Menendez : > On Fri, Mar 6, 2009 at 12:05 PM, Wolfgang Jeltsch > wrote: >> Am Freitag, 6. M?rz 2009 17:31 schrieben Sie: >>> What name would you suggest? >> >> If we wouldn?t have to care about compatibility, I would name the class String >> and drop the type alias String. >> >> It?s hard to come up with a good name since String is already taken. However, >> things like StringLike, Stringy, Chars etc. are probable still better than >> IsString since they describe the things (values of instances of that class) >> instead of stating a property of them. > > How about CharSequence? Characters ? From Jeremy.Gibbons at comlab.ox.ac.uk Fri Mar 6 12:49:24 2009 From: Jeremy.Gibbons at comlab.ox.ac.uk (Jeremy.Gibbons@comlab.ox.ac.uk) Date: Fri Mar 6 12:37:59 2009 Subject: [Haskell] Fully-funded doctoral studentships in dependently type programming at Oxford and Strathclyde Message-ID: <200903061749.n26HnO8T013809@merc4.comlab.ox.ac.uk> FULLY-FUNDED DOCTORAL STUDENTSHIPS IN DEPENDENTLY-TYPED PROGRAMMING AT OXFORD AND STRATHCLYDE A new EPSRC-funded project on Reusability and Dependent Types has just started, as a collaboration between the Functional Programming Laboratory at the University of Nottingham (Thorsten Altenkirch), the Algebra of Programming group at the University of Oxford (Jeremy Gibbons), and the Mathematically Structured Programming group at the University of Strathclyde (Neil Ghani and Conor McBride). We are all familiar with Milner's slogan that "well-typed programs cannot go wrong". Types express properties of programs; more expressive type systems - such as dependent typing - can state properties more precisely, providing stronger guarantees of behaviour and additional guidance in development. However, this expressivity comes at a price: more specific typing can reduce opportunities for code reuse. The goal of this project is to investigate techniques for promoting reuse without sacrificing precision; in particular, how can we layer dependently typed programs, imposing stronger invariants onto more general library code? Two fully-funded doctoral studentships are available to work in this area: one at Oxford (with JG) and one at Strathclyde (with CTM). Each covers stipend, fees (at the home/EU rate), equipment, and travel, and is for three and a half years from October 2009. The closing date for applications is 15th April 2009. For further details, see: http://web.comlab.ox.ac.uk/news/72-full.html http://personal.cis.strath.ac.uk/~conor/phds/ or contact one of the principal investigators on the project: Thorsten Altenkirch (txa@cs.nott.ac.uk) Neil Ghani (ng@cis.strathclyde.ac.uk) Jeremy Gibbons (jg@comlab.ox.ac.uk) Conor McBride (conor@strictlypositive.org) From allbery at ece.cmu.edu Fri Mar 6 13:47:49 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Mar 6 13:36:32 2009 Subject: [Haskell] string type class In-Reply-To: <200903061713.43573.g9ks157k@acme.softbase.org> References: <200903061233.36400.matthew.pocock@ncl.ac.uk> <200903061713.43573.g9ks157k@acme.softbase.org> Message-ID: <3F863341-3BE4-4BBF-8DD1-81A64FADE867@ece.cmu.edu> On 2009 Mar 6, at 11:13, Wolfgang Jeltsch wrote: > Am Freitag, 6. M?rz 2009 13:33 schrieb Matthew Pocock: >> It seems every time I look at hackage there is yet another stringy >> datatype. For lots of apps, the particular stringy datatype you use >> matters >> for performance but not algorithmic reasons. Perhaps this is a good >> time >> for someone to propose a stringy class? > > There is already the class IsString which was introduced for > overloaded string > literals. > > However, the name is terrible. No other Haskell class I know of has > an ?Is? at > its beginning. Classes don?t name properties (IsNum, IsMonoid, Has?). But their proper names were available. "String" is already taken for a concrete type, which complicates things; "IsString" was the simplest answer (and possibly avoided bikeshedding by being the answer nobody liked :) > Maybe you can also try to convince the masters of the IsString class > to change > the class name. My previous attempts through mailing list e-mails > seemed to > have no effect. :-( I think the problem here is you need to get buy-in from everyone involved, which includes libraries@ (String), ghc (IsString is recognized in order to enable string overloading), ByteString, and potentially anyone who uses any of the above. That said, if you want to officially propose it you need to read up on how to properly propose such changes to libraries@haskell.org. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell/attachments/20090306/51111667/PGP.bin From allbery at ece.cmu.edu Fri Mar 6 13:49:23 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Mar 6 13:37:54 2009 Subject: [Haskell] string type class In-Reply-To: <49a77b7a0903060924sae9bb49q7888344090e79ccb@mail.gmail.com> References: <200903061233.36400.matthew.pocock@ncl.ac.uk> <200903061713.43573.g9ks157k@acme.softbase.org> <200903061805.48991.g9ks157k@acme.softbase.org> <49a77b7a0903060924sae9bb49q7888344090e79ccb@mail.gmail.com> Message-ID: On 2009 Mar 6, at 12:24, David Menendez wrote: > How about CharSequence? I'd be tempted on first sight to assume that's related to Data.Seq. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell/attachments/20090306/12592704/PGP.bin From till at informatik.uni-bremen.de Fri Mar 6 14:13:18 2009 From: till at informatik.uni-bremen.de (Till Mossakowski) Date: Fri Mar 6 14:02:00 2009 Subject: [Haskell] string type class In-Reply-To: <3c6288ab0903060922y34b509dco49bdff8bbb7bdcff@mail.gmail.com> References: <200903061233.36400.matthew.pocock@ncl.ac.uk> <200903061713.43573.g9ks157k@acme.softbase.org> <40a414c20903060816q1eff8d2as5e36d80a825b86c1@mail.gmail.com> <7fb8f82f0903060828n1c89ec44ncc8244dbab3f0e56@mail.gmail.com> <3c6288ab0903060922y34b509dco49bdff8bbb7bdcff@mail.gmail.com> Message-ID: <49B175CE.5080009@informatik.uni-bremen.de> Sean Leather schrieb: > Like this? > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ListLike Indeed, a class StringLike is included there as well. Why not take or improve that one? Till From haskell at list.mightyreason.com Fri Mar 6 14:16:33 2009 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Fri Mar 6 14:05:07 2009 Subject: [Haskell] string type class In-Reply-To: <200903061233.36400.matthew.pocock@ncl.ac.uk> References: <200903061233.36400.matthew.pocock@ncl.ac.uk> Message-ID: <49B17691.9010402@list.mightyreason.com> Matthew Pocock wrote: > It seems every time I look at hackage there is yet another stringy > datatype. For lots of apps, the particular stringy datatype you use > matters for performance but not algorithmic reasons. Perhaps this is a > good time for someone to propose a stringy class? Not likely. I did define my own (private) class for regular expressions, to abstract over String, the ByteStrings, and Seq Char. But it is used in one place and is a wart that should be removed. The simple task of looping over the contents of a String (once, forward) is quite different from a Strict ByteString (using an index and a lookup). This means for decent efficiency I need two copies of my code, hand specialized to each case. "tail" or "(x:xs)" : very efficient for String (no allocation) "tail" or "uncons" : not efficient for ByteString (allocation, might as well convert to [Char] And indexing by Int is O(n) for String and O(1) for ByteString. So there are few algorithm that can access both efficiently. From bf3 at telenet.be Fri Mar 6 14:44:24 2009 From: bf3 at telenet.be (Peter Verswyvelen) Date: Fri Mar 6 14:32:45 2009 Subject: [Haskell] string type class In-Reply-To: <49B17691.9010402@list.mightyreason.com> References: <200903061233.36400.matthew.pocock@ncl.ac.uk> <49B17691.9010402@list.mightyreason.com> Message-ID: <013001c99e93$f3fac990$dbf05cb0$@be> What about AString or AnyString? > -----Original Message----- > From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] > On Behalf Of Chris Kuklewicz > Sent: Friday, March 06, 2009 8:17 PM > To: Matthew Pocock > Cc: haskell@haskell.org > Subject: Re: [Haskell] string type class > > Matthew Pocock wrote: > > It seems every time I look at hackage there is yet another stringy > > datatype. For lots of apps, the particular stringy datatype you use > > matters for performance but not algorithmic reasons. Perhaps this is > a > > good time for someone to propose a stringy class? > > Not likely. > > I did define my own (private) class for regular expressions, to > abstract over > String, the ByteStrings, and Seq Char. But it is used in one place and > is a > wart that should be removed. > > The simple task of looping over the contents of a String (once, > forward) is > quite different from a Strict ByteString (using an index and a lookup). > > This means for decent efficiency I need two copies of my code, hand > specialized > to each case. > > "tail" or "(x:xs)" : very efficient for String (no allocation) > "tail" or "uncons" : not efficient for ByteString (allocation, might as > well > convert to [Char] > > And indexing by Int is O(n) for String and O(1) for ByteString. > > So there are few algorithm that can access both efficiently. > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From dan.doel at gmail.com Fri Mar 6 18:43:55 2009 From: dan.doel at gmail.com (Dan Doel) Date: Fri Mar 6 18:32:29 2009 Subject: [Haskell] Definitions of purity and Lazy IO In-Reply-To: <1236314913.7500.35.camel@jonathans-macbook> References: <20090306041121.DE8EDABBB@Adric.metnet.fnmoc.navy.mil> <1236314913.7500.35.camel@jonathans-macbook> Message-ID: <200903061843.56078.dan.doel@gmail.com> On Thursday 05 March 2009 11:48:33 pm Jonathan Cast wrote: > > That is, for any program context C[] such that C[f1] is well-typed, > > the program C[f2] must too be well-typed, and if one can observe the > > result of C[f1] and of C[f2], the two observations must be identical. > > Every time? For every context? What about the context > > do > x <- getStdRandom random > y <- getStdRandom random > print $ [] x y > > ? By the standard above, f1 is not even observationally equivalent to > *itself*. One could theoretically dismiss this by saying that any particular IO context contains some random seed that determines the results of generating the random numbers. So, when you run the program and get different results, that's due to your actually running it in different contexts (with different seeds). However, it's possible to get this sort of non-determinism in other ways. For instance, consider the following fragment: do ctr <- newMVar 0 let inc = do i <- takeMVar ctr ; putMVar ctr (i+1) ; return i v1 <- newEmptyMVar v2 <- newEmptyMVar forkIO $ do inc >>= putMVar v1 forkIO $ do inc >>= putMVar v2 i1 <- takeMVar v1 i2 <- takeMVar v2 print $ i1 - i2 If forkIO provides real concurrency, this fragment should be capable of displaying either -1 or 1 (of course, everything happens too fast here, so I always end up getting -1, but I think the point is sound). So it's another context where (-) isn't equivalent to itself. So, to fix this up in the same way as the random example, you have to add something to the context that will supposedly completely determine the scheduling order of the threads in the program, so that when threads run in a different order, and you get a different result, you can say that you ran the program in a different context. But once we start doing that, how much more contrived is it to say that each context has some hidden state that determines how effects are interleaved with unsafeInterleaveIO such that we see the results we do (even though we know that isn't what's going on operationally; it isn't what's going on operationally with concurrency, either). The real issue is that lazy IO sometimes leads people to write buggier programs than they otherwise might. The same is true of, say, head and tail, but they are not impure by Sabry's definition, nor do they break referential transparency. They're 'impure' in that they're partial functions, but I'm not sure everyone's ready for Haskell to become a total language yet. :) Cheers, -- Dan From tomi at nomi.cz Thu Mar 5 14:48:30 2009 From: tomi at nomi.cz (=?iso-8859-2?Q?Tom=E1=B9_Janou=B9ek?=) Date: Sat Mar 7 12:53:07 2009 Subject: [Haskell] ACCOUNCE: storable 0.1 -- Storable type class for variable-sized data Message-ID: <20090305194830.GA14302@nomi.cz> I am pleased to announce that the first release of the storable library has been uploaded to Hackage. Let me describe it in a few sentences (copied from its haddock comments): This class fills the gap between Foreign.Storable and Data.Binary. It adds support for marshalling (finite) values of variable-sized data types, like lists or trees, while preserving the performance and memory efficiency one expects from the Storable class. It also provides a (monadic) syntactic sugar that takes care of alignment restrictions by itself and makes instance deriving easy. The performance goal has not been achieved yet, of course. We are using this class to serialize values of a data type representing vertices in a Haskell-generated graph for a model checker called DiVinE (C++). http://hackage.haskell.org/cgi-bin/hackage-scripts/package/storable -- Tom?? Janou?ek, a.k.a. Liskni_si, http://work.lisk.in/ From byorgey at seas.upenn.edu Sat Mar 7 18:20:26 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Mar 7 18:09:01 2009 Subject: [Haskell] Haskell Weekly News: Issue 108 - March 7, 2009 Message-ID: <20090307232026.GA9160@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090307 Issue 108 - March 07, 2009 --------------------------------------------------------------------------- Welcome to issue 108 of HWN, a newsletter covering developments in the [1]Haskell community. The ICFP programming contest will be held from 26-29th June! It's not too early to start thinking about putting a team together. Announcements tar 0.3.0.0. Duncan Coutts [2]announceda major new release of the [3]tar package for handling ".tar" archive files. This release has a completely new and much improved API. storable 0.1 -- Storable type class for variable-sized data. Tom?? Janou?ek [4]announced the first release of the [5]storable library, which fills the gap between Foreign.Storable and Data.Binary by adding support for marshalling (finite) values of variable-sized data types, like lists or trees, while preserving the performance and memory efficiency one expects from the Storable class. It also provides a (monadic) syntactic sugar that takes care of alignment restrictions by itself and makes instance deriving easy. CFP: Submit a talk proposal to CUFP. Kathleen Fisher [6]requested talk proposals for [7]CUFP. The Industrial Haskell Group. Duncan Coutts [8]announced the creation of the [9]Industrial Haskell Group (IHG). The IHG is an organisation to support the needs of commercial users of the Haskell programming language. Currently, the main activity of the IHG is a collaborative development scheme, in which multiple companies fund work on the Haskell development platform to their mutual benefit. The scheme has started with three partners of the IHG, including Galois and Amgen. pandoc 1.2. John MacFarlane [10]announced the release of [11]pandoc version 1.2. The most significant new feature is support for literate Haskell; you can now use pandoc directly on literate Haskell source files to produce syntax-highlighted HTML output. A Haskell binding for the Augeas API. Jude [12]announced a [13]Haskell FFI binding for the Augeas configuration editing API. Haskell Logo Voting will start soon!. Eelco Lempsink [14]announced that [15]voting for the new Haskell logo will begin on March 16! Everyone subscribed to haskell-cafe will receive a ballot; if you are not subscribed but would like to vote, email Eelco with the subject "haskell logo voting ballot request" and include a short, unique message. Happstack 0.2 Released. Matthew Elder [16]announced the [17]release of [18]Happstack 0.2. Extensible and Modular Generics for the Masses: emgm-0.3. Sean Leather [19]announced the third major release of [20]Extensible and Modular Generics for the Masses (EMGM), a library for generic programming in Haskell using type classes and a sum-of-products view. Deriving is now greatly improved, and there are several new functions, including case, everywhere, and everywhere'. major speed improvement: regex-tdfa reaches 1.0.0. ChrisK proudly [21]announced the version 1.0.0 release of [22]regex-tdfa. This is is not just a bug fix release; it is a serious improvement in the asymptotic running time of the library algorithms. Discussion Definitions of purity and Lazy IO. Oleg began a [23]discussion on lazy IO. Left fold enumerator - a real pearl overlooked?. G?nther Schmidt began a [24]discussion of left-fold enumerators and their current status within the community. Jobs Looking for a co-founder for a startup using Haskell. Ed McCaffrey [25]is looking for a co-founder to work on a startup music project in Haskell. Email Ed for more information. Fully-funded doctoral studentships in dependently type programming at Oxford and Strathclyde. Jeremy Gibbons [26]announced two fully-funded doctoral student positions in dependently-typed programming at [27]Oxford and [28]Strathclyde. Blog noise [29]Haskell news from the [30]blogosphere. * Holumbus: [31]First release of Holumbus-MapReduce. * FP Lunch: [32]Breadth first labelling. * Sean Leather: [33]Experiments with EMGM: Emacs org files. * Galois, Inc: [34]Call for Proposals: CUFP 2009. * Matthew Elder: [35]Happstack 0.2 Released. * Yi: [36]Lazy and Incremental Parsing: the paper. * Xmonad: [37]xmonad as a multi-head sliding block puzzle. * Don Stewart (dons): [38]Playing with GHC's parallel runtime. * Bjorn Buckwalter: [39]Extended sessions with the Haskell Curl bindings. * Manuel M T Chakravarty: [40]Installing GtK2Hs on a Mac with the native GTK+ OS X Framework.. * Alex Mason: [41]If you need speed, don't talk to main!. * Luke Palmer: [42]New game: SpaceBattle. * Galois, Inc: [43]Galois Tech Talk: Specializing Generators for High-Performance Monte-Carlo Simulation in Haskell. * Bjorn Buckwalter: [44]Programmer Man. * Conrad Parker: [45]Random code: Pretty printing durations in Haskell. * The GHC Team: [46]New paper: Runtime Support for Multicore Haskell. * ganesh: [47]London Haskell Users Group. * Manuel M T Chakravarty: [48]This is the performance of a dot product of two vectors of 10.... * Sean Leather: [49]Template Haskell 2.3 or Cabal 1.2? EMGM can't have both!. * Tom Schrijvers: [50]Complete and Decidable Type Inference for GADTs. * Galois, Inc: [51]Trustworthy Voting Systems. * Well-Typed.Com: [52]The Industrial Haskell Group. * Sean Leather: [53]Incremental fold, a design pattern. * Darcs: [54]darcs weekly news #19. * FP Lunch: [55]Container eating. About the Haskell Weekly News New editions are posted to [56]the Haskell mailing list as well as to [57]the Haskell Sequence and [58]Planet Haskell. [59]RSS is also available, and headlines appear on [60]haskell.org. To help create new editions of this newsletter, please see the information on [61]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [62]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://www.haskell.org//pipermail/haskell-cafe/2009-March/056870.html 3. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/tar 4. http://article.gmane.org/gmane.comp.lang.haskell.general/16934 5. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/storable 6. http://article.gmane.org/gmane.comp.lang.haskell.general/16904 7. http://cufp.galois.com/2009/call.html 8. http://article.gmane.org/gmane.comp.lang.haskell.general/16903 9. http://industry.haskell.org/ 10. http://article.gmane.org/gmane.comp.lang.haskell.general/16899 11. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pandoc 12. http://article.gmane.org/gmane.comp.lang.haskell.general/16897 13. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/augeas 14. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54201 15. http://community.haskell.org/~eelco/poll.html 16. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54144 17. http://blog.happstack.com/2009/03/04/happstack-02-released 18. http://blog.happstack.com/2009/03/04/happstack-02-released 19. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54035 20. http://www.cs.uu.nl/wiki/GenericProgramming/EMGM 21. http://article.gmane.org/gmane.comp.lang.haskell.cafe/53943 22. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex%2Dtdfa 23. http://thread.gmane.org/gmane.comp.lang.haskell.general/16914 24. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/53873 25. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54246 26. http://article.gmane.org/gmane.comp.lang.haskell.general/16927 27. http://web.comlab.ox.ac.uk/news/72-full.html 28. http://personal.cis.strath.ac.uk/~conor/phds/ 29. http://planet.haskell.org/ 30. http://haskell.org/haskellwiki/Blog_articles 31. http://holumbus.fh-wedel.de/blog/?p=17 32. http://sneezy.cs.nott.ac.uk/fplunch/weblog/?p=205 33. http://feedproxy.google.com/~r/splonderzoek/~3/6bxI33NIRMc/experiments-with-emgm-emacs-org-files.html 34. http://www.galois.com/blog/2009/03/05/call-for-proposals-cufp-2009/ 35. http://blog.happstack.com/2009/03/04/happstack-02-released/ 36. http://yi-editor.blogspot.com/2009/03/lazy-and-incremental-parsing-paper.html 37. http://xmonad.wordpress.com/2009/03/04/xmonad-as-a-multi-head-sliding-block-puzzle/ 38. http://donsbot.wordpress.com/2009/03/04/playing-with-ghcs-parallel-runtime/ 39. http://flygdynamikern.blogspot.com/2009/03/extended-sessions-with-haskell-curl.html 40. http://justtesting.org/post/83333955 41. http://axman6.homeip.net/blog/2009/03/if-you-need-speed-dont-talk-to-main.html 42. http://lukepalmer.wordpress.com/2009/03/04/new-game-spacebattle/ 43. http://www.galois.com/blog/2009/03/03/galois-tech-talk-specializing-generators-for-high-performance-monte-carlo-simulation-in-haskell/ 44. http://flygdynamikern.blogspot.com/2009/02/programmer-man.html 45. http://blog.kfish.org/2009/03/random-code-pretty-printing-durations.html 46. http://ghcmutterings.wordpress.com/2009/03/03/new-paper-runtime-support-for-multicore-haskell/ 47. http://www.londonhug.net/2009/03/03/80/ 48. http://justtesting.org/post/83014052 49. http://feedproxy.google.com/~r/splonderzoek/~3/WqqB1QrNZ_4/template-haskell-23-or-cabal-12-emgm.html 50. http://tomschrijvers.blogspot.com/2009/03/complete-and-decidable-type-inferennce.html 51. http://www.galois.com/blog/2009/03/02/trustworthy-voting-systems/ 52. http://blog.well-typed.com/2009/03/the-industrial-haskell-group/ 53. http://feedproxy.google.com/~r/splonderzoek/~3/tj_MkKqIlkQ/incremental-fold-design-pattern.html 54. http://blog.darcs.net/2009/03/darcs-weekly-news-19.html 55. http://sneezy.cs.nott.ac.uk/fplunch/weblog/?p=201 56. http://www.haskell.org/mailman/listinfo/haskell 57. http://sequence.complete.org/ 58. http://planet.haskell.org/ 59. http://sequence.complete.org/node/feed 60. http://haskell.org/ 61. http://haskell.org/haskellwiki/HWN 62. http://code.haskell.org/~byorgey/code/hwn/ From stefanschmidt42 at googlemail.com Sun Mar 8 09:47:25 2009 From: stefanschmidt42 at googlemail.com (Stefan Schmidt) Date: Sun Mar 8 09:42:04 2009 Subject: [Haskell] ANNOUNCE: Holumbus-MapReduce 0.0.1 Message-ID: <49B3CC6D.3080408@googlemail.com> The Holumbus framework is known for building specialized search-engines like the Hayoo! Haskell API search. Now, I'd like to announce the newest libraries of the Holumbus framework: Holumbus-MapReduce 0.0.1 Holumbus-Distribution 0.0.1 Holumbus-Storage 0.0.1 As part of my Master's Thesis at the University of Applied Sciences in Wedel, Germany, I have developed a library for building distributed MapReduce systems in Haskell. The existing Holumbus-Searchengine library already offers a MapReduce implementation, but it does not provide mechanisms for distributed computing. The newly developed Holumbus-MapReduce library contains of tools and modules for building individualized distributed MapReduce systems. Holumbus-MapReduce is based on two libraries: Holumbus-Distributed and Holumbus-Storage. Maybe they could be useful for building other distributed systems, not only a MapReduce system. Holumbus-Distribution consists of modules and tools for the implementation of distributed systems in general. Besides common data types and small helper functions, this library provides a mailbox-based data transfer mechanism. It offers an easy-to-use interface for inter- and intra-process communication like in Erlang or Mozart/Oz. Holumbus-Storage is designed to build a distributed storage system which can be linked into other programs. It is used by the MapReduce system for the data management. All three libraries are still under heavy development and should not be considered for creating applications in productive environments. But I think, it's time to give them to the community for suggestions on further development and features. Please email comments, bugs, etc. to sts@holumbus.org Stefan Schmidt Holumbus on Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Holumbus-MapReduce http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Holumbus-Distribution http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Holumbus-Storage link to my thesis: http://www.holumbus.org/redmine/attachments/37/thesis-mapreduce.pdf project homepage: http://www.holumbus.org/redmine/wiki/holumbus darcs repository (latest snapshots): http://holumbus.fh-wedel.de/holumbus/src From wchogg at gmail.com Sun Mar 8 22:34:33 2009 From: wchogg at gmail.com (Creighton Hogg) Date: Sun Mar 8 22:23:00 2009 Subject: [Haskell] ANN : happs-tutorial 0.8 Message-ID: <814617240903081934q7187df57p3ef5163e4bec4a24@mail.gmail.com> Hello, I'd like to announce the release of the happstack-0.2 compatible release of happs-tutorial on hackage and available for perusing on tutorial.happstack.com. A number of changes occurred in this release: * General cleanup of code for readability * Migration to the new Happstack.Server.SimpleHTTP api * Addition of a chapter on multimaster, the Spread Toolkit based system for syncing your applications across multiple Happstack instances. * Revised chapters on introducing Happstack.Server and Happstack.State, with an emphasis on simple, well-commented examples showing the orthogonality of these separate libraries. * Minor bug fixes Cheers, Creighton From fmics2009 at dsic.upv.es Mon Mar 9 09:46:09 2009 From: fmics2009 at dsic.upv.es (FMICS 2009 workshop chair) Date: Mon Mar 9 09:40:42 2009 Subject: [Haskell] [FMICS 2009] Third Call for Papers Message-ID: <49B51DA1.8000500@dsic.upv.es> FMICS 2009 - 3RD CALL FOR PAPERS Please visit: http://users.dsic.upv.es/workshops/fmics2009 ************************************************************ * 14th International Workshop on * * Formal Methods for Industrial Critical Systems * * FMICS 2009 * * * * November 2-3, 2009 * * Eindhoven, The Netherlands * ************************************************************ * ** NEWS ** * * * * >> Price for best paper -- awarded by EASST * * * ************************************************************ * * * LNCS proceedings * * Springer has confirmed that the proceedings * * will be published in their Lecture Notes in * * Computer Science series. * * * ************************************************************ IMPORTANT DATES --------------- Deadline for abstracts: 1st April Deadline for papers: 7 April Accept/Reject notification: 15 June Camera-ready version: 15 July Workshop: 2-3 November SCOPE OF THE WORKSHOP --------------------- The aim of the ERCIM FMICS workshop series is to provide a forum for researchers who are interested in the development and application of formal methods in industry. In particular, these workshops bring together scientists and engineers that are active in the area of formal methods and interested in exchanging their experiences in the industrial usage of these methods. These workshops also strive to promote research and development for the improvement of formal methods and tools for industrial applications. Topics include, but are not restricted to: - Design, specification, code generation and testing based on formal methods. - Methods, techniques and tools to support automated analysis, certification, debugging, learning, optimization and transformation of complex, distributed, real-time systems and embedded systems. - Verification and validation methods that address shortcomings of existing methods with respect to their industrial applicability (e.g., scalability and usability issues). - Tools for the development of formal design descriptions. - Case studies and experience reports on industrial applications of formal methods, focusing on lessons learned or identification of new research directions. - Impact of the adoption of formal methods on the development process and associated costs. - Application of formal methods in standardization and industrial forums. INVITED SPEAKERS ---------------- To be announced CO-CHAIRS --------- Maria Alpuente Tech. University Valencia, Spain Byron Cook Microsoft Research, UK PROGRAM COMMITTEE ------------------- Hassan Ait-Kaci Ilog, Canada Maria Alpuente Tech. University Valencia, Spain Thomas Arts IT-Univ. i Goteborg, Sweden Demis Ballis Universita Udine, Italy Josh Berdine Microsoft Research, UK Lubos Brim Masarykova Univ., Czech Republic Darren Cofer Rockwell Collins, USA Byron Cook Microsoft Research, UK Patrick Cousot Ecole Normale Superieure, France Santiago Escobar Tech. University Valencia, Spain Azadeh Farzan University of Toronto, Canada Hubert Garavel INRIA Rhone-Alpes, France Stefania Gnesi ISTI-CNR, Italy Alexey Gotsman University of Cambridge, UK Holger Hermanns Universitat Saarlandes, Germany Christophe Joubert Tech. University Valencia, Spain Daniel Kroening ETH Zurich, Switzerland Michael Leuschel Universitat Dusseldorf, Germany Pedro Merino Universidad de Malaga, Spain Juan Jose Moreno-Navarro Univ. Politecnica Madrid, Spain Corina Pasareanu NASA Ames Research Center, USA Jaco van de Pol Univ. Twente, The Netherlands Murali Rangarajan Honeywell, USA Jakob Rehof Tech. Univ. Dortmund, Germany Andrey Rybalchenko Max-Planck-Gesellschaft, Germany Marcel Verhoef Chess, The Netherlands Martin Wirsing Universitat Munchen, Germany Hongseok Yang University of London, UK Greta Yorsh IBM Watson Research Center, USA ERCIM FMICS WG COORDINATOR -------------------------- Alessandro Fantechi Univ. Firenze, ISTI-CNR, Italy WORKSHOP CHAIR -------------- Christophe Joubert Tech. University Valencia, Spain PAPER SUBMISSIONS ----------------- Submissions must be made electronically through the EasyChair system. Papers should be up to 16 pages in LNCS format, with the names and affiliations of the authors and a clear and informative abstract. Additional details may be included in a clearly marked appendix, which will be read at the discretion of the program committee. All submissions must report on original research. Submitted papers must not have previously appeared in a journal or conference with published proceedings and must not be concurrently submitted to any other peer-reviewed workshop, symposium, conference or archival journal. Any partial overlap with any such published or concurrently submitted paper must be clearly indicated. Case study papers should identify lessons learned, validate theoretical results (such as scalability of methods), or provide specific motivation for further research and development. The workshop proceedings will be published in the Springer series Lecture Notes in Computer Science (LNCS). CO-LOCATION ----------- FMICS 2009 is part of the first Formal Methods Week (FMweek), which will bring together a choice of events in the area, including TESTCOM/FATES (Conference on Testing of Communicating Systems and Workshop on Formal Approaches to Testing of Software), FACS (Formal Aspects of Component Software), PDMC (Parallel and Distributed Methods of verifiCation), FM2009 (Symposium of Formal Methods Europe), CPA (Communicating Process Architectures), FAST (Formal Aspects of Security and Trust), FMCO (Formal Methods for Components and Objects), and the REFINE Workshop. For the latest information on FMweek, see http://www.win.tue.nl/fmweek. ************************************************************ * * * +============================================+ * * | | * * | ** FMweek ** | * * | | * * +============================================+ * * | CPA | FACS | FAST | * * +--------------------------------------------+ * * | FM2009 | FMCO | FMICS | * * +--------------------------------------------+ * * | PDMC | REFINE | TESTCOM/FATES | * * +--------------------------------------------+ * * | http://www.win.tue.nl/fmweek | * * +============================================+ * * * ************************************************************ From johan.tibell at gmail.com Tue Mar 10 05:41:54 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Mar 10 05:30:19 2009 Subject: [Haskell] Google Summer of Code 2009 In-Reply-To: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <90889fe70903100241m259af961ic5e96159ce635d07@mail.gmail.com> On Tue, Feb 10, 2009 at 3:26 PM, Malcolm Wallace wrote: > Gentle Haskellers, > > The Google Summer of Code will be running again this year. ?Once again, > haskell.org has the opportunity to bid to become a mentoring > organisation. ?(Although, as always, there is no guarantee of > acceptance.) > > If you have ideas for student projects that you think would benefit the > Haskell community, now is the time to start discussing them on mailing > lists of your choice. ?We especially encourage students to communicate > with the wider community: if you keep your ideas private, you have a > much worse chance of acceptance than if you develop ideas in > collaboration with those who will be your "customers", end-users, or > fellow-developers. ?This is the open-source world! > > The timeline is that Haskell.org will apply for GSoC membership between > 9-13 March, and if we are successful, students can submit applications > between 23 March - 3 April. Google is now accepting applications: http://google-opensource.blogspot.com/2009/03/google-summer-of-code-applications-now.html From kyagrd at gmail.com Tue Mar 10 05:56:47 2009 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Tue Mar 10 05:48:25 2009 Subject: [Haskell] ANN: sparsebit 0.5 - Sparse Bitmaps for Pattern Match Coverage Message-ID: sparsebit - Sparse Bitmaps for Pattern Match Coverage http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sparsebit This library packages the functional peal paper 'Sparse Bitmaps for Pattern Match Coverage' submitted to ICFP 2009 by Ki Yung Ahn and Tim Sheard. You can look up the tutorial-like paper and the talk slides, which are availabel at: http://kyagrd.dyndns.org/wiki/SparseBitmapsForPatternMatchCoverage Abstract: Pattern matching coverage over Algebraic Data Types(ADTs) has most often been studied in the context of pattern compilation algorithms. However, it is worth considering the pattern matching coverage problem in isolation, since general solutions will be independent of the specifics of any implementation or language. We define an intuitive and mathematically well-established bit masking semantics for pattern match coverage. We design and implement a sparse bitmap data structure, which realizes this semantics in a compact and flexible manner. This bitmap data structure supports computing coverage solutions of large programs incrementally from coverage solutions of sub-programs. It can also be used as a common data representation for pattern coverage shared between different tools (e.g., compilers, linting tools, software analysis tools) that need pattern match coverage information. Additional source files Type.hs and TestType.hs packaged with this library provides the examples and QuickCheck extracted from the paper to demonstrate how to use this library. ==================================================================== Some additional notes: Personally, I am very happy to upload my first project on Hackage. If you are looking for simple and elegant way of describing pattern match coverage or testing exhaustiveness of pattern matching, we hope this may give you a better insight. This is a reference implementation, but I think it is still usable to some extent. One might want to define monadic version of the library functions and operators since the type representation in the program analysis tools might be monadic for implementation reasons (easy to generate fresh type variables) and performance reasons (to exploit sharing while unification of type variables). And in such cases, more optimized implementation of tensor product may be possible as well. And there are some other issues discussed in the paper as well. I was not able to make the haddock documentation appear in Hackage, although I have no problem generating documentation using "cabal haddock" locally. It would be nice if there is a way to see some diagnose of warning or error messages why haddock failed on Hackage. -- Ahn, Ki Yung From Malcolm.Wallace at cs.york.ac.uk Tue Mar 10 06:19:41 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Mar 10 06:11:44 2009 Subject: [Haskell] Google Summer of Code 2009 In-Reply-To: <90889fe70903100241m259af961ic5e96159ce635d07@mail.gmail.com> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <90889fe70903100241m259af961ic5e96159ce635d07@mail.gmail.com> Message-ID: <20090310101941.3fb41484.Malcolm.Wallace@cs.york.ac.uk> > > The Google Summer of Code will be running again this year. ?Once > > again, haskell.org has the opportunity to bid to become a mentoring > > organisation. ?(Although, as always, there is no guarantee of > > acceptance.) > > Google is now accepting applications: Indeed. Since I am (perhaps by default) the GSoC org admin for haskell.org once again this year, and will shortly need to list our mentors on our application form, I am now soliciting volunteers to be mentors. Please email me directly. The mentoring group has two main jobs: * To look after students and their projects if/when they are accepted. If you have suggested, or feel strongly about, or have experience relevant to a particular project (currently on the trac[1], or reddit[2] - if not, then add it!), please consider volunteering to mentor it. This requires a commitment of maybe up to five hours a week (but often less) during the student coding phase (23rd May - 17th Aug). Having multiple mentors for a single project area is no problem - it just means more backup for students. * To review and rank student proposals. This requires a commitment of several hours across the review period (roughly 23rd March - 15th April), and also some enthusiasm for generally promoting projects that will benefit the Haskell community as a whole. The reviewers include all those who are willing to look after students for the summer. Of course there is no guarantee that your project will actually get student participation, but if you don't play at this stage, you definitely won't get one! Regards, Malcolm [1] http://hackage.haskell.org/trac/summer-of-code/ [2] http://www.reddit.com/r/haskell_proposals/ From klee at cs.tu-berlin.de Tue Mar 10 11:11:22 2009 From: klee at cs.tu-berlin.de (Dirk Kleeblatt) Date: Tue Mar 10 10:56:27 2009 Subject: [Haskell] ANNOUNCE: Harpy 0.4.4 - Runtime code generation for x86 machine code Message-ID: <49B6831A.2010609@cs.tu-berlin.de> Dear Haskell community, we are pleased to announce the release of Harpy 0.4.1, a library for runtime code generation for x86 machine code. Harpy is available from Hackage or from Harpy's homepage: http://uebb.cs.tu-berlin.de/harpy/ *** New in version 0.4.1 *** New Instances: - Many of Harpy's types are now instances of Eq. New instructions: - Added support for the prefetching instructions PREFETCH0, PREFETCH1, PREFETCH2 and PREFETCHNTA. Bug fixes: - Harpy.X86Disassembler.disassembleBloc was too strict and caused stack overflows for large inputs. This was fixed. - Disassembler: The instruction prefix list was not cleared when beginning to parse a new instruction. This caused incorrect disassembly of SSE instructions. - Disassembler: A bug has been fixed in the parsing routine for the addressing mode "scaled index + 32 bit offset" without base register. Enjoy, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3225 bytes Desc: S/MIME Cryptographic Signature Url : http://www.haskell.org/pipermail/haskell/attachments/20090310/cd5cec69/smime.bin From conor at strictlypositive.org Tue Mar 10 12:00:38 2009 From: conor at strictlypositive.org (Conor McBride) Date: Tue Mar 10 11:49:00 2009 Subject: [Haskell] Microsoft PhD Scholarship at Strathclyde Message-ID: <8997C117-FD41-42CD-8785-536F6143E7EA@strictlypositive.org> Apologies for crossposting. Please forward this message to individuals or lists who may be interested. In addition to the recently advertised PhD position at Strathclyde on "Reusability and Dependent Types", I am delighted to advertise the following PhD opportunity. {--------------------------------------------------------- -- Haskell Types with Numeric Constraints ---------------- ---------------------------------------------------------} We are grateful to Microsoft Research for their sponsorship of this project, which includes an internship, and with it the chance to make a real difference to world of principled but practical programming. The project investigates the practical and theoretical impact of extending Haskell's type system with numeric expressions (representing sizes, or ranges, or costs, for example) and constraints capturing richer safety properties than are currently managed by static typing. It has three strands: (1) to investigate type inference with numeric constraints, (2) to investigate new programming structures, patterns, and techniques which exploit numeric indexing, and (3) to study the performance benefits derivable from richer guarantees. A bright student could bring significant benefits to developers using Haskell, a language with increasing industrial traction ? not least at Microsoft. Work on the Glasgow Haskell Compiler, at Strathclyde! {---------------------------------------------------------} The position is fully funded, covering stipend, fees (at the home/EU rate), equipment, and travel, starting in October 2009. The closing date for applications is 15th April 2009. For further details, see: http://personal.cis.strath.ac.uk/~conor/phds/ or email me (conor@cis.strath.ac.uk). I look forward to hearing from you. Yours &c Conor McBride From jwlato at gmail.com Tue Mar 10 15:28:00 2009 From: jwlato at gmail.com (John Lato) Date: Tue Mar 10 15:16:17 2009 Subject: [Haskell] Announce: iteratee-0.1.0 Message-ID: <9979e72e0903101228r77ab01ccyf26aa99f81e41d24@mail.gmail.com> I am pleased to announce the hackage release of iteratee-0.1.0. This library implements enumerators and iteratees as proposed by Oleg Kiselyov (http://okmij.org/ftp/Haskell/Iteratee/). Significant differences from his original code include: - Seeking is allowed within any monad; the specific RBIO monad is neither required nor provided. - Data buffers may be of arbitrary types as specified by the StreamChunk type class. This allows for user-provided buffer types (e.g. arrays, vectors, etc.). Instances are provided for lists and ByteStrings. This, in conjunction with seeking, allows for efficient processing of binary data in addition to text. - Cross-platform support. Currently this is slightly less efficient than the Posix operations, but should run on any system targeted by a Haskell compiler. Although basic I/O specific enumerators are provided, this library should allow seamless interoperation with user-provided iteratees and enumerators. I hope that this flexibility will encourage a much wider adoption of enumerator-based IO in the Haskell community. This library is experimental, and the API is subject to change if it will seem advantageous. Patches are welcome: the darcs repo is at http://inmachina.net/~jwlato/haskell/iteratee . Discussion and comments are also always welcome. I would like to acknowledge several individuals for their contributions and suggestions: Oleg Kiselyov Paulo Tanimoto Johan Tibell Cheers, John Lato From johan.tibell at gmail.com Tue Mar 10 15:57:00 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Mar 10 15:45:19 2009 Subject: [Haskell] Announce: iteratee-0.1.0 In-Reply-To: <9979e72e0903101228r77ab01ccyf26aa99f81e41d24@mail.gmail.com> References: <9979e72e0903101228r77ab01ccyf26aa99f81e41d24@mail.gmail.com> Message-ID: <90889fe70903101257m5d771fddk792340fea3469529@mail.gmail.com> On Tue, Mar 10, 2009 at 8:28 PM, John Lato wrote: > I am pleased to announce the hackage release of iteratee-0.1.0. ?This > library implements enumerators and iteratees as proposed by Oleg > Kiselyov (http://okmij.org/ftp/Haskell/Iteratee/). ?Significant > differences from his original code include: > > ?- Seeking is allowed within any monad; the specific RBIO monad is > neither required nor provided. > ?- Data buffers may be of arbitrary types as specified by the > StreamChunk type class. ?This allows for user-provided buffer types > (e.g. arrays, vectors, etc.). ?Instances are provided for lists and > ByteStrings. ?This, in conjunction with seeking, allows for efficient > processing of binary data in addition to text. > ?- Cross-platform support. ?Currently this is slightly less efficient > than the Posix operations, but should run on any system targeted by a > Haskell compiler. Here's the Hackage link for the lazy among us: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/iteratee-0.1.0 Cheers, Johan From tanimoto at arizona.edu Tue Mar 10 16:20:58 2009 From: tanimoto at arizona.edu (Paulo Tanimoto) Date: Tue Mar 10 16:09:18 2009 Subject: [Haskell] Announce: iteratee-0.1.0 In-Reply-To: <90889fe70903101257m5d771fddk792340fea3469529@mail.gmail.com> References: <9979e72e0903101228r77ab01ccyf26aa99f81e41d24@mail.gmail.com> <90889fe70903101257m5d771fddk792340fea3469529@mail.gmail.com> Message-ID: On Tue, Mar 10, 2009 at 2:57 PM, Johan Tibell wrote: > On Tue, Mar 10, 2009 at 8:28 PM, John Lato wrote: >> I am pleased to announce the hackage release of iteratee-0.1.0. ?This >> library implements enumerators and iteratees as proposed by Oleg >> Kiselyov (http://okmij.org/ftp/Haskell/Iteratee/). ?Significant >> differences from his original code include: >> >> ?- Seeking is allowed within any monad; the specific RBIO monad is >> neither required nor provided. >> ?- Data buffers may be of arbitrary types as specified by the >> StreamChunk type class. ?This allows for user-provided buffer types >> (e.g. arrays, vectors, etc.). ?Instances are provided for lists and >> ByteStrings. ?This, in conjunction with seeking, allows for efficient >> processing of binary data in addition to text. >> ?- Cross-platform support. ?Currently this is slightly less efficient >> than the Posix operations, but should run on any system targeted by a >> Haskell compiler. > > Here's the Hackage link for the lazy among us: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/iteratee-0.1.0 > > Cheers, > > Johan Nice job, John! Please keep posting on your blog, so we can see your findings with audio processing and examples of iteratee. If Windows users are interested, I just cabal-installed it on Windows XP and the examples seem to run. Paulo From dons at galois.com Tue Mar 10 16:21:03 2009 From: dons at galois.com (Don Stewart) Date: Tue Mar 10 16:10:14 2009 Subject: [Haskell] Announce: iteratee-0.1.0 In-Reply-To: References: <9979e72e0903101228r77ab01ccyf26aa99f81e41d24@mail.gmail.com> <90889fe70903101257m5d771fddk792340fea3469529@mail.gmail.com> Message-ID: <20090310202103.GE1077@whirlpool.galois.com> tanimoto: > On Tue, Mar 10, 2009 at 2:57 PM, Johan Tibell wrote: > > On Tue, Mar 10, 2009 at 8:28 PM, John Lato wrote: > >> I am pleased to announce the hackage release of iteratee-0.1.0. ?This > >> library implements enumerators and iteratees as proposed by Oleg > >> Kiselyov (http://okmij.org/ftp/Haskell/Iteratee/). ?Significant > >> differences from his original code include: > >> > >> ?- Seeking is allowed within any monad; the specific RBIO monad is > >> neither required nor provided. > >> ?- Data buffers may be of arbitrary types as specified by the > >> StreamChunk type class. ?This allows for user-provided buffer types > >> (e.g. arrays, vectors, etc.). ?Instances are provided for lists and > >> ByteStrings. ?This, in conjunction with seeking, allows for efficient > >> processing of binary data in addition to text. > >> ?- Cross-platform support. ?Currently this is slightly less efficient > >> than the Posix operations, but should run on any system targeted by a > >> Haskell compiler. > > > > Here's the Hackage link for the lazy among us: > > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/iteratee-0.1.0 > > > > Cheers, > > > > Johan > > Nice job, John! Please keep posting on your blog, so we can see your > findings with audio processing and examples of iteratee. Would love to see performance/handle-scalability numbers, too! From v.dijk.bas at gmail.com Wed Mar 11 12:27:42 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Mar 11 12:15:58 2009 Subject: [Haskell] Announce: iteratee-0.1.0 In-Reply-To: <9979e72e0903101228r77ab01ccyf26aa99f81e41d24@mail.gmail.com> References: <9979e72e0903101228r77ab01ccyf26aa99f81e41d24@mail.gmail.com> Message-ID: On Tue, Mar 10, 2009 at 8:28 PM, John Lato wrote: > I am pleased to announce the hackage release of iteratee-0.1.0. Nice! I think it would be nice if you make Monoid a superclass of StreamChunk and remove the 'empty' and 'append' methods. I attached a darcs patch that does just that, adds the necessary Monoid instances and updates all code to work with Monoids. regards, Bas -------------- next part -------------- A non-text attachment was scrubbed... Name: monoid_superclass.dpatch Type: application/octet-stream Size: 7542 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell/attachments/20090311/73e4ba10/monoid_superclass.obj From jwlato at gmail.com Wed Mar 11 16:36:23 2009 From: jwlato at gmail.com (John Lato) Date: Wed Mar 11 16:24:38 2009 Subject: [Haskell] Announce: iteratee-0.1.0 In-Reply-To: References: <9979e72e0903101228r77ab01ccyf26aa99f81e41d24@mail.gmail.com> Message-ID: <9979e72e0903111336k752b0b97nb81e00e82d1e802@mail.gmail.com> On Wed, Mar 11, 2009 at 4:27 PM, Bas van Dijk wrote: > On Tue, Mar 10, 2009 at 8:28 PM, John Lato wrote: >> I am pleased to announce the hackage release of iteratee-0.1.0. > > Nice! > > I think it would be nice if you make Monoid a superclass of > StreamChunk and remove the 'empty' and 'append' methods. > > I attached a darcs patch that does just that, adds the necessary > Monoid instances and updates all code to work with Monoids. > Thanks very much for this; it looks great. Incidentally, one of the items planned for iteratee is some restructuring of types, in particular the StreamChunk class. I would very much like to make further steps in this direction. John From v.dijk.bas at gmail.com Thu Mar 12 04:09:58 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Thu Mar 12 03:58:14 2009 Subject: [Haskell] Announce: iteratee-0.1.0 In-Reply-To: <9979e72e0903111336k752b0b97nb81e00e82d1e802@mail.gmail.com> References: <9979e72e0903101228r77ab01ccyf26aa99f81e41d24@mail.gmail.com> <9979e72e0903111336k752b0b97nb81e00e82d1e802@mail.gmail.com> Message-ID: On Wed, Mar 11, 2009 at 9:36 PM, John Lato wrote: > On Wed, Mar 11, 2009 at 4:27 PM, Bas van Dijk wrote: >> On Tue, Mar 10, 2009 at 8:28 PM, John Lato wrote: >>> I am pleased to announce the hackage release of iteratee-0.1.0. >> >> Nice! >> >> I think it would be nice if you make Monoid a superclass of >> StreamChunk and remove the 'empty' and 'append' methods. >> >> I attached a darcs patch that does just that, adds the necessary >> Monoid instances and updates all code to work with Monoids. >> > > Thanks very much for this; it looks great. ?Incidentally, one of the > items planned for iteratee is some restructuring of types, in > particular the StreamChunk class. ?I would very much like to make > further steps in this direction. > > John > Here's another bigger and perhaps more controversial patch that generalizes the String error type to any type of error that is an instance of the Control.Monad.Error.Error class. So the main change is: -data (SC.StreamChunk c el) => StreamG c el = EOF | Error String | Chunk (c el) +data (SC.StreamChunk c el, Error err) => StreamG c el err = EOF | Error err | Chunk (c el) You should carefully review this patch because I made changes in parts of the code that I haven't tried to understand yet. I just made everything type check (which is usually sufficient in Haskell). regards, Bas -------------- next part -------------- A non-text attachment was scrubbed... Name: generalize_error.dpatch Type: application/octet-stream Size: 66127 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell/attachments/20090312/d739be66/generalize_error-0001.obj From waldmann at imn.htwk-leipzig.de Thu Mar 12 06:08:28 2009 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Mar 12 05:56:45 2009 Subject: [Haskell] Call for papers: Workshop on Termination (WST 2009) Message-ID: <49B8DF1C.1040905@imn.htwk-leipzig.de> Dear all, the 10th Intl. Workshop on Termination welcomes contributions from the functional programming community. See the general call for papers below, and let me add a few words here. The typical functional (compiler) programmer needs - termination of programs - termination of program transformations (rules) - termination of program analysis (type checking/inference) So I'm sure the workshop topic is highly relevant, and we are looking for *your* contributions. Also, we have an annual competition for automated termination provers, http://termination-portal.org/wiki/Termination_Competition and since 2007 it contains a Haskell category. The problems there are taken directly from the Standard Prelude. So if you have some kind of Haskell source code analyzer that knows something about termination (perhaps only internally), then you're welcome turn it into a Haskell termination prover and submit it to this competition. (Details will be discussed at the workshop.) Best regards, Johannes Waldmann. ..................................................................... Tenth International Workshop on Termination (WST 2009) Leipzig, Germany, June 3-5, 2009 http://www.imn.htwk-leipzig.de/wst09/ Termination is a fundamental topic in computer science. Classical undecidability results show that termination is difficult. On the other hand, programs are usually required to terminate. So methods are needed that prove termination and non-termination automatically for a wide range of programs. Termination proofs are essential not only for program verification, but also as components of program transformation systems. The topic is challenging both in theory (mathematical logic, proof theory) and practice (software development, formal methods), and many interesting ramifications are yet to be explored. The 10th International Workshop on Termination will delve into all aspects of termination of processes. It will continue the sequence of successful workshops held in St. Andrews (1993), La Bresse (1995), Ede (1997), Dagstuhl (1999), Utrecht (2001), Valencia (2003), Aachen (2004), Seattle (2006), and Paris (2007). It will attain the same friendly atmosphere as those past workshops. The intent is to bring together, in an informal setting, researchers interested in all aspects of termination, whether this interest be practical or theoretical, primary or derived. The workshop shall help exchange ideas from term rewriting and from the various programming language communities. Contributions from the imperative, constraint, functional, and logic programming communities, and papers investigating new applications of termination are particularly welcome. Program Committee: Frederic Blanqui, INRIA, FR and Tsinghua University, CN Byron Cook, Microsoft Corporation, US Alfons Geser, HTWK Leipzig, DE (chair) Michael Hanus, Universit?t Kiel, DE Janis Voigtlander, Technische Universit?t Dresden, DE Local organization: Johannes Waldmann, HTWK Leipzig, DE Important Dates: Paper submission 19 April 2009 Notification 26 April 2009 Final Paper Version 3 May 2009 Conference Venue: The workshop will be held in the city of Leipzig, at the conference center Mediencampus Villa Ida. Hosting institution: Hochschule fur Technik, Wirtschaft und Kultur Leipzig, in cooperation with Leipzig School of Media and Medienstiftung der Sparkasse Leipzig. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20090312/3d542254/signature.bin From alson at alsonkemp.com Thu Mar 12 22:22:17 2009 From: alson at alsonkemp.com (Alson Kemp) Date: Thu Mar 12 22:10:28 2009 Subject: [Haskell] ANNOUNCE: Turbinado V0.6 Message-ID: <2629c41e0903121922r4a73454fj1241ec6f1c44bfeb@mail.gmail.com> Turbinado (http://www.turbinado.org) is a Rails-ish Model-View-Controller web serving framework for Haskell. It's in heavy development, is making excellent progress and is designed to make building websites in Haskell a joy. It?s been long enough since Turbinado V0.4 that I figured I?d skip V0.5 and go straight to announcing Turbinado V0.6. Lots of new excellent features: * By popular demand, support for CGI serving. Apparently some web hosts don?t support HTTP proxying, so some folks requested CGI support. * Statically compiled Layouts, Views, Controllers (to complement dynamic loading). * Support for ?.format? in routes. If a request path is ?/User/List.xml?, then the following View will be called: /App/Views/User/ListXml.hs. * Lower case paths. * Support for cookies (see here for examples). * Encrypted cookie sessions (see here to see how to use them). * Much easier installs using cabal-install. * Support for GHC 6.10. GHC 6.8 is no longer supported. Turbinado V0.7 will be all about: * Documentation. (seriously.) * User authentication. * Tutorials. From kyagrd at gmail.com Sat Mar 14 04:41:23 2009 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Sat Mar 14 04:29:51 2009 Subject: [Haskell] Re: Lazy IO breaks purity In-Reply-To: References: <20090305021220.7FC65AB11@Adric.metnet.fnmoc.navy.mil> Message-ID: Lennart Augustsson wrote: > I don't see any breaking of referential transparence in your code. > Every time you do an IO operation the result is basically > non-deterministic since you are talking to the outside world. > You're assuming the IO has some kind of semantics that Haskell makes > no promises about. > > I'm not saying that this isn't a problem, because it is. > But it doesn't break referential transparency, it just makes the > semantics of IO even more complicated. +1 If we are in a situation where really have to take this seriously, we already have a well-known standard trick for this kind of problem: refine the monad! We can always define NonInterlavedIO monad for the operations that does not use unsafeInterleaveIO. We have been doing this all the time including the recent STM stuff. > (I don't have a formal proof that unsafeInterleaveIO cannot break RT, > but I've not seen an example where it does yet.) > > -- Lennart From byorgey at seas.upenn.edu Sat Mar 14 09:58:27 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Mar 14 09:46:41 2009 Subject: [Haskell] Haskell Weekly News: Issue 109 - March 14, 2009 Message-ID: <20090314135827.GA30843@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090314 Issue 109 - March 14, 2009 --------------------------------------------------------------------------- Welcome to issue 109 of HWN, a newsletter covering developments in the [1]Haskell community. Congratulations to the authors of RWH on their [2]Jolt award! Some cool libraries released this week (as usual), and some really cool PhD [3]opportunities at Strathclyde. Also, it seems that I was censured last week for not including any quotes in the HWN, which is because tunes.org (which hosts the #haskell logs) was down while I was putting it together. So, this time I've included quotes going back two weeks, I HOPE YOU'RE HAPPY Community News Tom DuBuisson (TomMD) has [4]moved to Portland and will be starting a PhD at Portland State soon. Announcements darcs fundraising drive - only $720 left to go!. Eric Kow [5]announced that [6]donations are still being accepted to help pay for travel to the upcoming Haskell hackathon. So far we have raised $280, so we're almost a third of the way there. Think you can help? Vintage BASIC 1.0. Lyle Kopnicky [7]announced the initial release of [8]Vintage BASIC, an interpreter for microcomputer-era BASIC. Fully unit-tested, it faithfully implements the common elements of the language. On the web site, you can find 102 games from the classic book BASIC Computer Games, all of which run flawlessly. Have fun! ThreadScope: Request for features for the performance tuning of parallel and concurrent Haskell programs. Satnam Singh [9]requested feedback on infrastructure for logging run-time events and a graphical viewer program called [10]ThreadScope. The goal is for these features to make it into the next release of GHC. torch-0.1. Yusaku Hashimoto [11]announced a new unit test framework, [12]torch-0.1. sparsebit 0.5 - Sparse Bitmaps for Pattern Match Coverage. Ki Yung Ahn [13]announced the release of the [14]sparsebit library. This library packages the functional peal paper [15]Sparse Bitmaps for Pattern Match Coverage submitted to ICFP 2009 by Ki Yung Ahn and Tim Sheard. happs-tutorial 0.8. Crieghton Hogg [16]announced the release of [17]happs-tutorial 0.8, which is compatible with [18]happstack-0.2. A number of changes have occurred in this release, including general code cleanup, migration to the new Happstack.Server.SimpleHTTP API, and more. Future 1.1.0 concurrency library. ChrisK [19]announced the [20]future package, which ought to do what C++ standard futures/promises do, plus a bit more. The main operation is forkPromise :: IO a -> IO (Promise a), which sets the "IO a" operation running in a fresh thread; the eventual result can be accessed in many ways (non-blocking, blocking, blocking with timeout). Holumbus-MapReduce 0.0.1. Stefan Schmidt [21]announced three new libraries: [22]Holumbus-MapReduce, [23]Holumbus-Distribution, and [24]Holumbus-Storage, which provide tools for building distributed systems. These libraries are used as the backbone of the [25]Holumbus search engine. Turbinado V0.6. Alson Kemp [26]announced the release of [27]Turbinado 0.6, a Rails-ish Model-View-Controller web serving framework for Haskell. New features include support for CGI serving, statically compiled Layouts, Views, and Controllers, lower case paths, support for cookies and encrypted cookie sessions, easier installation, and support for GHC 6.10. iteratee-0.1.0. John Lato [28]announced the hackage release of [29]iteratee-0.1.0. This library implements enumerators and iteratees [30]as proposed by Oleg Kiselyov. Harpy 0.4.4 - Runtime code generation for x86 machine code. Dirk Kleeblatt [31]announced the release of [32]Harpy 0.4.1, a library for runtime code generation for x86 machine code. The new release features additional Eq instances, support for new prefetching instructions, and some bug fixes. Discussion Suggestion for a Haskell mascot. Maur?cio [33]suggested using a sloth as the Haskell mascot. If you would like to know how to say 'sloth' in just about every language ever, read this thread. Jobs Microsoft PhD Scholarship at Strathclyde. Conor McBride [34]announced another PhD opportunity at Strathclyde, sponsored by Microsoft Research, to investigate the practical and theoretical impact of extending Haskell's type system with numeric expressions (representing sizes, or ranges, or costs, for example) and constraints capturing richer safety properties than are currently managed by static typing. Blog noise [35]Haskell news from the [36]blogosphere. * Braden Shepherdson: [37]Pimp Your XMonad #4: Urgency Hooks. * Thomas M. DuBuisson: [38]Explicit Parallelism via Thread Pools. * Ketil Malde: [39]Current developments. Ongoing development of the biohaskell libraries for bioinformatics. * Philip Wadler: [40]Cafe Scientifique. Philip will be giving a talk, "Proofs are Programs: 19th Century Logic and 21st Century Computing", on Monday in Edinburgh. * Yi: [41]Yi 0.6.0 Release Notes. * Alson Kemp: [42]ANNOUNCE: Turbinado V0.6. * GHC / OpenSPARC Project: [43]Thread activity plotting. * Real-World Haskell: [44]We won a Jolt Award!. * Real-World Haskell: [45]Real World Haskell on the Kindle 2. * Christophe Poucet (vincenz): [46]Bootstrapping cabal. * Gtk2HS: [47]Mickinator File Manager. * Osfameron: [48](rough) Grids in Haskell. Some notes on representing 2D grids in Haskell. * Manuel M T Chakravarty: [49]These graphs summarise the performance of Data Parallel Haskell.... * GHC / OpenSPARC Project: [50]Project midpoint. * GHC / OpenSPARC Project: [51]The GNU Debugger and me. * Don Stewart (dons): [52]Evolving faster Haskell programs. Using genetic algorithms to find optimal flag combinations. * Xmonad: [53]Xmonad and the Gimp. * Xmonad: [54]xmonad on eee. * Mark Wassell: [55]Conversations with a type checker. * Holumbus: [56]Holumbus-MapReduce on Hackage. Some neat libraries for building distributed systems! * Darcs: [57]darcs weekly news #20. * Nick Mudge: [58]First Bay Area Haskell Meeting. * Dan Piponi (sigfpe): [59]Dinatural Transformations and Coends. Quotes of the Week * mmorrow: when i first saw haskell i was like "holy shitfork! that's what i've been trying to do in C for forever!" * pastah: the maybe monad is like cheating. everything is so awesomelly easy. * wli: Monads are like constipation. Comonads are like Ex-Lax. * TomMD: Never trust IO. * Axman6: let blah f x = f (blah f x) in blah ("blah "++) "" * MyCatVerbs: Lazy IO is implemented in terms of unsafePerformIO, you, you, you silly bipedal carbon-based organism. * MyCatVerbs: Amdahl's law is mostly to be used for making people feel depressed. * Axman6: -ddump-occur-anal <- another terrible name... * AchimSchneider: Finite automata don't go bottom in any case, at least not if you don't happen to shoot them and their health drops below zero. * ski: the truth (semantics), the whole truth (completeness), and nothing but the truth (soundness) * f4hy: wait you can do a show on an infinite list?! (I am starting to think haskell is not a programming language, it is evil wizardry) * Baughn: concat $ forM [(1,2), (4,5)] $ \(a,b) -> show (b,a+b) About the Haskell Weekly News New editions are posted to [60]the Haskell mailing list as well as to [61]the Haskell Sequence and [62]Planet Haskell. [63]RSS is also available, and headlines appear on [64]haskell.org. To help create new editions of this newsletter, please see the information on [65]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [66]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://www.realworldhaskell.org/blog/2009/03/12/we-won-a-jolt-award/ 3. http://article.gmane.org/gmane.comp.lang.haskell.general/16944 4. http://tommd.wordpress.com/2009/03/13/explicit-parallelism-via-thread-pools/ 5. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54758 6. http://www.darcs.net/donations.html 7. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54652 8. http://www.vintage-basic.net/ 9. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54521 10. http://raintown.org/threadscope 11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54445 12. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/torch 13. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54436 14. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sparsebit 15. http://kyagrd.dyndns.org/wiki/SparseBitmapsForPatternMatchCoverage 16. http://www.haskell.org//pipermail/haskell-cafe/2009-March/057305.html 17. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happs%2Dtutorial 18. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happstack 19. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54409 20. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/future 21. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54325 22. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Holumbus%2DMapReduce 23. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Holumbus-Distribution 24. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Holumbus-Storage 25. http://www.holumbus.org/redmine/wiki/holumbus 26. http://article.gmane.org/gmane.comp.lang.haskell.general/16953 27. http://www.turbinado.org/ 28. http://article.gmane.org/gmane.comp.lang.haskell.general/16945 29. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/iteratee 30. http://okmij.org/ftp/Haskell/Iteratee/ 31. http://article.gmane.org/gmane.comp.lang.haskell.general/16942 32. http://uebb.cs.tu-berlin.de/harpy/ 33. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/54418 34. http://article.gmane.org/gmane.comp.lang.haskell.general/16944 35. http://planet.haskell.org/ 36. http://haskell.org/haskellwiki/Blog_articles 37. http://braincrater.wordpress.com/2009/03/14/pimp-your-xmonad-4-urgency-hooks/ 38. http://tommd.wordpress.com/2009/03/13/explicit-parallelism-via-thread-pools/ 39. http://blog.malde.org/index.php/2009/03/13/current-developments/ 40. http://wadler.blogspot.com/2009/03/cafe-scientifique.html 41. http://yi-editor.blogspot.com/2009/03/yi-060-release-notes.html 42. http://www.alsonkemp.com/haskell/announce-turbinado-v06/ 43. http://ghcsparc.blogspot.com/2009/03/thread-activity-plotting.html 44. http://www.realworldhaskell.org/blog/2009/03/12/we-won-a-jolt-award/ 45. http://www.realworldhaskell.org/blog/2009/03/13/real-world-haskell-on-the-kindle-2/ 46. http://cpoucet.wordpress.com/2009/03/12/bootstrapping-cabal/ 47. http://haskell.org/gtk2hs/archives/2009/03/10/mickinator-file-manager/ 48. http://greenokapi.net/blog/2009/03/10/rough-grids-in-haskell/ 49. http://justtesting.org/post/85103645 50. http://ghcsparc.blogspot.com/2009/03/project-midpoint.html 51. http://ghcsparc.blogspot.com/2009/03/gnu-debugger-and-me.html 52. http://donsbot.wordpress.com/2009/03/09/evolving-faster-haskell-programs/ 53. http://xmonad.wordpress.com/2009/03/08/xmonad-and-the-gimp/ 54. http://xmonad.wordpress.com/2009/03/08/xmonad-on-eee/ 55. http://www.poundstone.org/blog/?p=23 56. http://holumbus.fh-wedel.de/blog/?p=18 57. http://blog.darcs.net/2009/03/darcs-weekly-news-20.html 58. http://nickmudge.info/?post=115 59. http://blog.sigfpe.com/2009/03/dinatural-transformations-and-coends.html 60. http://www.haskell.org/mailman/listinfo/haskell 61. http://sequence.complete.org/ 62. http://planet.haskell.org/ 63. http://sequence.complete.org/node/feed 64. http://haskell.org/ 65. http://haskell.org/haskellwiki/HWN 66. http://code.haskell.org/~byorgey/code/hwn/ From felipe.lessa at gmail.com Sun Mar 15 11:17:54 2009 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Sun Mar 15 11:06:15 2009 Subject: [Haskell] ANNOUNCE: dzen-utils 0.1 Message-ID: <20090315151754.GA9277@kira.casa> Hello! I'm please to announce dzen-utils 0.1. I don't feel like it is ready to be released, but let's see how everything goes. :) == WHAT == dzen-utils contains various utilities for creating dzen input strings in a type-safe way using some combinators, including the ability to apply colors locally (instead of applying for everything beyond some point). It can also emulate dbar and gdbar, do automatic padding, and more. == WHY == I don't like to write bash scripts for dzen, and I don't like the way xmobar treats its configuration and its inability to show anything other than text. This package is a short-term solution for my problems. Maybe I'll write xmozen in the future. ;) == WHERE, HOW, etc. == It is in Hackage already, go get it[1]. Please see the documentation of System.Dzen for some small examples. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dzen-utils Thanks for your time, -- Felipe. From wss at cs.nott.ac.uk Mon Mar 16 04:59:22 2009 From: wss at cs.nott.ac.uk (Wouter Swierstra) Date: Mon Mar 16 04:47:36 2009 Subject: [Haskell] ANN: The Monad.Reader (13) Message-ID: I am pleased to announce that a new issue of The Monad.Reader is now available: http://www.haskell.org/haskellwiki/The_Monad.Reader The Monad.Reader is a quarterly magazine about functional programming. Issue 13 consists of the following four articles: * Stephen Hicks Rapid Prototyping in TEX * Brent Yorgey The Typeclassopedia * Chris Eidhof, Eelco Lempsink Book Review: "Real World Haskell" * Derek Elkins Calculating Monads with Category Theory Special thanks to Ashley Yakeley for his help with publishing The Monad.Reader on the Haskell wiki. If you'd like to write something for the next issue of The Monad.Reader, please get in touch. I haven't fixed the deadline for the next issue, but it should be mid-May or thereabouts. Wouter From nr at cs.tufts.edu Mon Mar 16 11:47:42 2009 From: nr at cs.tufts.edu (Norman Ramsey) Date: Mon Mar 16 11:35:42 2009 Subject: [Haskell] Re: scoped type variables In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C334CBA721CD@EA-EXMSG-C334.europe.corp.microsoft.com> (sfid-H-20090316-052706-+71.36-1@multi.osbf.lua) References: <20090314221715.8D34B78838B@homedog.cs.tufts.edu> <638ABD0A29C8884A91BC5FB5C349B1C334CBA721CD@EA-EXMSG-C334.europe.corp.microsoft.com> (sfid-H-20090316-052706-+71.36-1@multi.osbf.lua) Message-ID: <20090316154743.12F45104CE6@lakeland.eecs.harvard.edu> [Opening discussion to broader audience: I asked Simon PJ about scoped type variables and type abbreviations] > | With scoped type variables, it would be useful to be able to define > | a type abbreviation in a where clause, so that the scoped > | type variable could be used on a right-hand side. Apparently > | this wasn't done. Was there any technical reason why not? > > Would you care to give an example? Do you mean > f x = e where a = Int No. I give an example below, but I've just spent 10 minutes grubbing through the Haskell 98 Report so I can phrase the question more precisely: Given the extension to scoped type variables, I believe that the 'type' abbreviation declaration should have been 'promoted' from syntactic category 'topdecl' to syntactic category 'decl', because it is convenient and useful to be able to exploit a scoped type variable in a type abbreviation. Was this possibility simply overlooked, or was a deliberate choice made not to do it? Here is a synopsis of code I would like to write: solve :: forall m l a . Graph m l -> Fuel -> DFM a (a, Fuel) solve = solveGraph where -- in the defintions below, type variable 'a' is free -- on the RHS but is bound by the forall above type FactKont b = Graph m l -> a -> Fuel -> DFM a b type FuelKont b = Graph m l -> Fuel -> DFM a b solveMid :: m -> FactKont b -> FactKont b solveLast :: l -> FuelKont b -> FactKont b ... For my sanity I'd like to define type abbreviations that refer to 'm' and 'l' also... Under the current regime, I'm forced to do what amounts to lambda lifting on the type abbreviations. Not only does this lead to a extra type parameters which distract from the main event, but in floating the type abbreviation out to top level, I am forced to choose a unique name for it, which I might prefer not to do if the same module contains several similar functions with similar (but not identical) type abbreviations. Of course the naming issue arises even in Haskell 98, but the ability to bring type variables into scope in a 'where' clause adds urgency. > There are lots of design issues. For example, in GHC today, a scoped type > variable stands for a type *variable* not for a *type*. I took the other > approach initially, but I think this is better I know this distinction is important in instance declarations. Presumably it also means that the scoped type variable can unify with something else during type inference? I fear that without seeing some formalism I can't be too sure what's going on---is there a technical report somewhere that explains the distinction? In any case, I hope this question is orthogonal to the problem of permitting a type declaration as a 'decl' in a where clause and not a mere lonely 'topdecl'. Is anybody else keen to have this ability? Norman From rlaemmel at gmail.com Mon Mar 16 21:52:41 2009 From: rlaemmel at gmail.com (Ralf Laemmel) Date: Mon Mar 16 21:40:38 2009 Subject: [Haskell] indirectly recursive dictionaries In-Reply-To: References: Message-ID: {- Recursive instance heads as in ... ?instance C0 (x,Bool) => C0 x ... are Ok if we allow for typechecking scheme as described in "SYB with class". The main idea is to assume C0 x in proving the preconditions of the body of the clause. This is also works for mutual recursion among type classes and instances to the extent exercised in ditto paper. What about the below example though? Here recursion detours through an extra class in a way that leads to nonterminating typechecking with GHC 6.10.1. Does anyone agree that a constraint resolution scheme like the one mentioned could be reasonably expected to cover this case? Regards, Ralf -} {-# OPTIONS -fglasgow-exts #-} {-# OPTIONS -fallow-overlapping-instances #-} {-# OPTIONS -fallow-undecidable-instances #-} -- Direct recursion terminates (typechecking-wise) class C0 x ?where ?m0 :: x -> () ?m0 = const undefined instance (C0 x, C0 y) => C0 (x,y) instance C0 Bool instance C0 (x,Bool) => C0 x foo :: () foo = m0 (1::Int) -- Indirect recursion does not terminate (typechecking-wise) class C1 x ?where ?m1 :: x -> () ?m1 = const undefined instance (C1 x, C1 y) => C1 (x,y) instance C1 Bool instance (C2 x y, C1 (y,Bool)) => C1 x class C2 x y | x -> y instance C2 Int Int -- It is this declaration that causes nontermination of typechecking. bar :: () bar = m1 (1::Int) From john at repetae.net Mon Mar 16 22:39:44 2009 From: john at repetae.net (John Meacham) Date: Mon Mar 16 22:27:43 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler Message-ID: <20090317023944.GN8842@sliver.repetae.net> Hi, I am pleased to announce jhc 0.6.0, It has been a long time since an official release, so there have been a lot of changes. Jhc is an optimizing haskell compiler that focuses on creating fast and portable code. Jhc is still mainly of interest to jhc hackers and developers than the general haskell public, but it is starting to see use in embedded development with haskell so I decided to make more public announcements of major releases in the future. some links: The jhc homepage: http://repetae.net/computer/jhc/ Installation Instructions: http://repetae.net/computer/jhc/building.shtml The jhc manual: http://repetae.net/computer/jhc/manual.html And I am happy to announce, there is now a yum repository* for jhc and my other projects (such as DrIFT), so if you use an rpm based linux distribution, you can keep up to date with jhc official releases by doing: ; rpm -i http://repetae.net/yum/repetae-repo-1.0-3.noarch.rpm ; yum install jhc A couple recent changes: jhc now comes bundled with the 'containers' and 'applicative' library making it much easier to compile many haskell programs out there. (Data.Graph, Data.IntMap, Data.IntSet, Data.Map, Data.Sequence, Data.Set, Data.Tree, Control.Applicative, Control.Arrow, Control.Category, Data.Foldable, Data.Traversable) signifigant speed and resource usage improvements in compilation time. transparent cross compilation support for creating windows programs on a unix box. (or iPhone/Nokia Tablet/etc..) If you are interested in jhc development, please sign up on the jhc mailing list here: http://www.haskell.org/mailman/listinfo/jhc John * I would love to get proper 'deb's and BSD packages built also automatically, if anyone wants to help with this, please join the list and let us know. -- John Meacham - ?repetae.net?john? From Tom.Schrijvers at cs.kuleuven.be Tue Mar 17 04:08:58 2009 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Tue Mar 17 03:58:08 2009 Subject: [Haskell] indirectly recursive dictionaries In-Reply-To: References: Message-ID: > {- > > Recursive instance heads as in ... >  instance C0 (x,Bool) => C0 x > ... are Ok if we allow for typechecking scheme as described in "SYB with class". > The main idea is to assume C0 x in proving the preconditions of the > body of the clause. > This is also works for mutual recursion among type classes and > instances to the extent exercised in ditto paper. > > What about the below example though? > Here recursion detours through an extra class in a way that leads to > nonterminating typechecking with GHC 6.10.1. > Does anyone agree that a constraint resolution scheme like the one > mentioned could be reasonably expected to cover this case? > > Regards, > Ralf > > -} > > {-# OPTIONS -fglasgow-exts #-} > {-# OPTIONS -fallow-overlapping-instances #-} > {-# OPTIONS -fallow-undecidable-instances #-} > > -- Direct recursion terminates (typechecking-wise) > > class C0 x >  where >  m0 :: x -> () >  m0 = const undefined > > instance (C0 x, C0 y) => C0 (x,y) > instance C0 Bool > instance C0 (x,Bool) => C0 x > > foo :: () > foo = m0 (1::Int) > > > -- Indirect recursion does not terminate (typechecking-wise) > > class C1 x >  where >  m1 :: x -> () >  m1 = const undefined > > instance (C1 x, C1 y) => C1 (x,y) > instance C1 Bool > instance (C2 x y, C1 (y,Bool)) => C1 x > > class C2 x y | x -> y > instance C2 Int Int The cyclic dictionaries approach is a bit fragile. The problem appears to be here that GHC alternates exhaustive phases of constraint reduction and functional dependency improvement. The problem is that in your example you need both for detecting a cycle. This can happen: C1 Int ==> 3rd C1 inst C2 Int y, C1 (y,Bool) ==> 1st C1 inst C2 Int y, C1 y, C1 Bool ==> 2nd C1 inst C2 Int y, C1 y ==> 3rd C1 inst C2 Int y, C2 y z, C1 (z,Bool) ==> ... where all the constraint are different because fresh variables are introduced. What you want to happen is: C1 Int ==> 3rd C1 inst C2 Int y, C1 (y,Bool) ==> 1st C1 inst C2 Int y, C1 y, C1 Bool ==> 2nd C1 inst C2 Int y, C1 y ==> C2 FD improvement {Int/y} <<<< C2 Int Int, C1 Int ==> C1 Int cycle detected C2 Int Int ==> C2 1st instance {} It seems that you want improvement to happen at a higher priority than GHC does now. Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From oleg at okmij.org Tue Mar 17 04:59:41 2009 From: oleg at okmij.org (oleg@okmij.org) Date: Tue Mar 17 04:50:15 2009 Subject: [Haskell] Re: indirectly recursive dictionaries Message-ID: <20090317085941.50EE1AF97@Adric.metnet.fnmoc.navy.mil> Ralf wrote: > class C1 x > where > m1 :: x -> () > m1 = const undefined > instance (C1 x, C1 y) => C1 (x,y) > instance C1 Bool > instance (C2 x y, C1 (y,Bool)) => C1 x > class C2 x y | x -> y > instance C2 Int Int > bar :: () > bar = m1 (1::Int) I believe it works very well (meaning bar typechecks and even runs) if we either add an instance instance C1 Int or change the instance of C2 to instance C2 Int Bool Otherwise, the problem really has no solution, and looping is an indication. I used GHC 6.8.3.... From rturk at science.uva.nl Tue Mar 17 10:17:29 2009 From: rturk at science.uva.nl (Remi Turk) Date: Tue Mar 17 10:05:49 2009 Subject: [Haskell] ANNOUNCE: libffi 0.1 released Message-ID: <20090317141729.GA20381@ow127.science.uva.nl> I am happy to announce libffi 0.1, binding to the C library libffi, allowing C functions to be called whose types are not known before run-time. Why? Sometimes you can't use the haskell foreign function interface because you parse the type of the function from somewhere else, i.e. you're writing an interpreter for a language that has an FFI itself. What? The main function it exports is: callFFI :: FunPtr a -> RetType b -> [Arg] -> IO b And because code is worth a thousand words, here a small program that uses C to write a 1Gb buffer of random garbage to a file: > import System.Posix.DynamicLinker > import Foreign.LibFFI > > main = do > malloc <- dlsym Default "malloc" > creat <- dlsym Default "creat" > write <- dlsym Default "write" > let sz = 2 ^ 30 > buf <- callFFI malloc (retPtr retVoid) [argCSize sz] > fd <- callFFI creat retCInt [argString "/tmp/test", argCUInt 0o644] > n <- callFFI write retCSize [argCInt fd, argPtr buf, argCSize sz] > putStrLn $ show n ++ " bytes written" It should work on any 32/64bits machine on which libffi works, but has been primarily tested on linux x86_64. The current libffi is not exception-safe (exception = memory leak) and callFFI has quite some overhead that would be unnecessary with another api. It is, however, very easy to use :) More interesting examples are included in examples/ in the package. Where? Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/libffi Module docs: http://www.science.uva.nl/~rturk/doc/libffi-0.1 Cheers, Remi From rlaemmel at gmail.com Tue Mar 17 11:00:40 2009 From: rlaemmel at gmail.com (Ralf Laemmel) Date: Tue Mar 17 10:48:46 2009 Subject: [Haskell] Re: indirectly recursive dictionaries In-Reply-To: References: Message-ID: Re: Tom: Thanks. This was an excellent analysis. Re: Oleg: Obviously, I don't want to add instance C1 int. Rather C1 Int should be implied by the existing scheme for recursive dictionary construction and bar should typecheck fine. (foo already relies on this scheme.) However, as Tom pointed out, we would need FD improvement to happen more intermittently. ... and that's the Gretchen-Frage I guess whether there is a reasonable (enough) scheme of doing so? The *intention* sounds reasonable. In fact, to me it sounds less reasonable to defer FD improvement and go on with an unnecessarily general goal C1 (y, Bool), i.e., without taking advantage of the fact that y is functionally determined by a constant type Int. That's a slippery slope - I know. Ralf PS: Is this a topic that should relocate to haskell-cafe, if there is further interest? I don't know ... On Tue, Mar 17, 2009 at 2:52 AM, Ralf Laemmel wrote: > {- > > Recursive instance heads as in ... > ?instance C0 (x,Bool) => C0 x > ... are Ok if we allow for typechecking scheme as described in "SYB with class". > The main idea is to assume C0 x in proving the preconditions of the > body of the clause. > This is also works for mutual recursion among type classes and > instances to the extent exercised in ditto paper. > > What about the below example though? > Here recursion detours through an extra class in a way that leads to > nonterminating typechecking with GHC 6.10.1. > Does anyone agree that a constraint resolution scheme like the one > mentioned could be reasonably expected to cover this case? > > Regards, > Ralf > > -} > > {-# OPTIONS -fglasgow-exts #-} > {-# OPTIONS -fallow-overlapping-instances #-} > {-# OPTIONS -fallow-undecidable-instances #-} > > -- Direct recursion terminates (typechecking-wise) > > class C0 x > ?where > ?m0 :: x -> () > ?m0 = const undefined > > instance (C0 x, C0 y) => C0 (x,y) > instance C0 Bool > instance C0 (x,Bool) => C0 x > > foo :: () > foo = m0 (1::Int) > > > -- Indirect recursion does not terminate (typechecking-wise) > > class C1 x > ?where > ?m1 :: x -> () > ?m1 = const undefined > > instance (C1 x, C1 y) => C1 (x,y) > instance C1 Bool > instance (C2 x y, C1 (y,Bool)) => C1 x > > class C2 x y | x -> y > instance C2 Int Int > > -- It is this declaration that causes nontermination of typechecking. > bar :: () > bar = m1 (1::Int) > From ccshan at post.harvard.edu Tue Mar 17 20:32:02 2009 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Tue Mar 17 20:48:15 2009 Subject: [Haskell] Re: scoped type variables References: <20090314221715.8D34B78838B@homedog.cs.tufts.edu> <638ABD0A29C8884A91BC5FB5C349B1C334CBA721CD@EA-EXMSG-C334.europe.corp.microsoft.com> <20090316154743.12F45104CE6@lakeland.eecs.harvard.edu> Message-ID: <21s596-15g.ln1@mantle.rutgers.edu> Norman Ramsey wrote in article <20090316154743.12F45104CE6@lakeland.eecs.harvard.edu> in gmane.comp.lang.haskell.general: > ... > In any case, I hope this question is orthogonal to the problem of > permitting a type declaration as a 'decl' in a where clause and not a > mere lonely 'topdecl'. Is anybody else keen to have this ability? Yes, and I'd like to say "let type ... = ... in" and/or "where type ... = ..." inside type expressions as well. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Who would have thought LISP would come back to life. Steve Bourne, in an interview about Bourne Shell. From oleg at okmij.org Tue Mar 17 23:26:53 2009 From: oleg at okmij.org (oleg@okmij.org) Date: Tue Mar 17 23:17:25 2009 Subject: [Haskell] Re: indirectly recursive dictionaries Message-ID: <20090318032653.50C67AF97@Adric.metnet.fnmoc.navy.mil> Tom Schrijvers wrote: > The cyclic dictionaries approach is a bit fragile. The problem appears to > be here that GHC alternates exhaustive phases of constraint reduction and > functional dependency improvement. The problem is that in your example you > need both for detecting a cycle. It seems we can convince GHC to do constraint reduction and improvement in the order we desire. The key is to use the continuation-passing style -- which forces things to happen in the right order, both at the run-time and at the compile time. I took the liberty to flesh out the example a bit more, to verify that recursive dictionaries are indeed constructed and used. The trace statement shows it. {-# OPTIONS -fglasgow-exts #-} {-# OPTIONS -fallow-overlapping-instances #-} {-# OPTIONS -fallow-undecidable-instances #-} import Debug.Trace class C1 x where m1 :: x -> Int instance (C1 x, C1 y) => C1 (x,y) where m1 (x,y) = m1 x + m1 y instance C1 Bool where m1 = fromEnum -- Was: instance (C2 x y, C1 (y,Bool)) => C1 x instance C2CPS x (C1K Bool) => C1 x where m1 x = trace "recursive C1" $ c2invoke (C1K True) x newtype C1K a = C1K a -- The class C2CPS below is a CPS version of the class C2 below -- class C2 x y | x -> y where c2 :: x -> y -- instance C2 Int Int where c2 = id -- The functional dependency becomes implicit class C2CPS x k where c2invoke :: k -> x -> Int instance Apply k Int Int => C2CPS Int k where c2invoke k x = apply k x class Apply f x y | f x -> y where apply:: f -> x -> y instance C1 (b,a) => Apply (C1K a) b Int where apply (C1K a) x = m1 (x,a) -- It is this declaration that was causing nontermination of typechecking. -- Not any more bar :: Int bar = m1 (1::Int) From S.J.Thompson at kent.ac.uk Wed Mar 18 17:03:07 2009 From: S.J.Thompson at kent.ac.uk (S.J.Thompson) Date: Wed Mar 18 16:51:01 2009 Subject: [Haskell] How do students learn Haskell? Postgraduate project at University of Kent Message-ID: Funding is available for this postgraduate project, supervised by Simon Thompson and Sally Fincher, in collaboration with Jurriaan Hage, Utrecht University. To apply visit http://www.cs.kent.ac.uk/research/pg/ How do students learn Haskell? As users and teachers of Haskell, we have some sense of how people, both experienced programmers and novices, learn to program in Haskell. This sense is based on experience - as learners ourselves, perhaps, or through teaching. We propose an alternative approach, based on the wealth of data collected through the instrumented version of the Helium system for Haskell [1]. This collects information of the programs compiled, the errors they generate, and how learners use the system in fixing those errors, and so we can see precisely the way that learners use these tools while they are learning. This is a joint project of the Functional Programming and Computing Education groups at the University of Kent, and the Helium group at Utrecht. The CompEd group has experience of working on this sort of project [2], and the FP group has wide experience of teaching functional languages, particularly Haskell [3]. [1] Helium http://www.cs.uu.nl/wiki/Helium [2] ICER 2006 http://www.jadud.com/people/mcj/files/2006-icer-jadud.pdf [3] Craft http://www.cs.kent.ac.uk/people/staff/sjt/craft2e/ From malcolm.wallace at cs.york.ac.uk Wed Mar 18 19:20:06 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Mar 18 19:08:22 2009 Subject: [Haskell] Google Summer of Code Message-ID: <3F402DAF-3AA5-4CD9-B493-8E582CD78D9F@cs.york.ac.uk> I am pleased to announce that haskell.org has once again been accepted as a mentoring organisation, for the 2009 Google Summer of Code. Student applications open on Monday (23rd March) at 1900 UTC, for a period of 12 days (until Fri 3rd April, also at 1900 UTC). Students applicants are encouraged to interact with the community via mailing lists, prior, during, and after the submission of their ideas for projects. In general terms, project ideas that benefit the whole community (e.g. infrastructure like ghc, cabal, libraries) will be preferred over things of more marginal interest (e.g. games). Unless you make a _really_ good case, of course! Because (sadly) the darcs community did not get accepted as a separate organisation this year, haskell.org will be willing to accept proposals relating to darcs (as it has done in previous years), but of course they will be competing in the general pool, alongside all the other ideas. Also, we are still accepting mentors. Regards, Malcolm From sylvain.nahas at googlemail.com Wed Mar 18 19:16:06 2009 From: sylvain.nahas at googlemail.com (sylvain) Date: Wed Mar 18 19:08:39 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <20090317023944.GN8842@sliver.repetae.net> References: <20090317023944.GN8842@sliver.repetae.net> Message-ID: <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> Hi, This compiler is very promising, for the least. Here is a small dummy Haskell program. countdown :: Int -> IO () countdown 0 = putStrLn "finished" countdown x = do putStrLn (show x) countdown (x-1) main = countdown 10000000 and the C program that comes to closest. #include int main(void) { int i; for(i=0; i<10000000; i++) { printf("%d\n",i); } printf("finished\n"); return 0; } GHC is 6.10.1, gcc is 4.3.2, jhc is 0.6.0 arch is i386/Linux(Ubuntu) $ ghc hello.hs -o hello1 $ jhc hello.hs -o hello2 $ gcc hello.c -o hello3 What about the size of the executables? $ ls -l hello1 hello2 hello3 493567 hello1 16803 hello2 9083 hello3 let strip them. 309492 hello1 10092 hello2 5664 hello3 In the case of jhc, there is definitively room for some improvements. I dare not say what I think of ghc. Now, let run them. $ time ./hello1 > /dev/null real 0m12.092s user 0m12.005s sys 0m0.052s $ time ./hello2 > /dev/null real 0m2.016s user 0m1.016s sys 0m1.000s $ time ./hello3 > /dev/null real 0m2.609s user 0m2.588s sys 0m0.020s Actually, times varie between runs. It tends to decrease (except for the ghc generated binary), so I suppose it is due to OS cache effects. Yet, I consistently observed that, according to "time", hello2 (jhc) runs _faster_ than hello3 (gcc). Something is wrong: how can Haskell be faster than C? Last but not least, as well as generating fast code, jhc can make good use of a C cross-compiler as back-end. Well done. Sylvain Nahas From allbery at ece.cmu.edu Wed Mar 18 19:42:14 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Mar 18 19:30:18 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> References: <20090317023944.GN8842@sliver.repetae.net> <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> Message-ID: On 2009 Mar 18, at 19:16, sylvain wrote: > Actually, times varie between runs. It tends to decrease (except for > the > ghc generated binary), so I suppose it is due to OS cache effects. > Yet, I consistently observed that, according to "time", hello2 (jhc) > runs _faster_ than hello3 (gcc). > > Something is wrong: how can Haskell be faster than C? I suspect if you profile you'll find that Haskell's show is faster than C's printf, especially if the appropriate show instance is selected at compile time. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell/attachments/20090318/72d81cdf/PGP.bin From hz at inf.elte.hu Thu Mar 19 02:21:54 2009 From: hz at inf.elte.hu (=?iso-8859-2?Q?Horv=E1th_Zolt=E1n?=) Date: Thu Mar 19 02:10:00 2009 Subject: [Haskell] CFP TFP 2009 and Functional Programming summer school: CEFP 2009 Message-ID: <88C55C9C92561741A80422B15F25C4BFD9FDBB60A2@exch02.inf.elte.hu> Second call for papers 10th SYMPOSIUM ON TRENDS IN FUNCTIONAL PROGRAMMING TFP 2009 SELYE JANOS UNIVERSITY, KOMARNO, SLOVAKIA June 2-4, 2009 http://www.inf.elte.hu/tfp_cefp_2009 *** The registration and paper submission is now open! *** The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results. Acceptance for the conference is based on full papers or extended abstracts, and a formal post-symposium refereeing process selects the best articles presented at the symposium for publication in a high-profile volume. TFP 2009 is hosted by the Selye Janos University, Komarno, Slovakia, and it is co-located with the 3rd Central-European Functional Programming School (CEFP 2009), which is held immediately before TFP 2009 (May 25-30). IMPORTANT DATES (ALL 2009) * Paper Submission: March 31 (extended) * Notification of Acceptance: April 9 * Camera Ready Symposium Proceedings Paper: April 24 * TFP Symposium: June 2-4, 2009 * Post Symposium Paper Submission: June 30 * Notification of Acceptance: September 7 * Camera Ready Revised Paper: September 21 SCOPE OF THE SYMPOSIUM As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: * Research: leading-edge, previously unpublished research. * Position: on what new trends should or should not be. * Project: descriptions of recently started new projects. * Evaluation: what lessons can be drawn from a finished project. * Overview: summarizing work with respect to a trendy subject. Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience- oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Contributions on the following subject areas are particularly welcomed: * Dependently Typed Functional Programming * Validation and Verification of Functional Programs * Debugging for Functional Languages * Functional Programming and Security * Functional Programming and Mobility * Functional Programming to Animate/Prototype/Implement Systems from Formal or Semi-Formal Specifications * Functional Languages for Telecommunications Applications * Functional Languages for Embedded Systems * Functional Programming Applied to Global Computing * Functional GRIDs * Functional Programming Ideas in Imperative or Object-Oriented Settings (and the converse) * Interoperability with Imperative Programming Languages * Novel Memory Management Techniques * Parallel/Concurrent Functional Languages * Program Transformation Techniques * Empirical Performance Studies * Abstract/Virtual Machines and Compilers for Functional Languages * New Implementation Strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2009 program chairs, Zoltan Horvath and Viktoria Zsok at tfp2009@inf.elte.hu SUBMISSION AND DRAFT PROCEEDINGS Acceptance of articles for presentation at the symposium is based on the screening process of full papers (15 pages) and extended abstracts (at least 3 pages). TFP encourages PhD students to submit papers. PhD students may request the program committee to provide extensive feedback on their full papers at the time of submission. Full papers describing work accepted for presentation must be completed before the symposium for publication in the draft proceedings. Further details can be found at the TFP 2009 website. POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the draft symposium proceedings, we continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. PROGRAM COMMITTEE * Peter Achten (symp-chair), Radboud University Nijmegen, NL * John Clements, California Polytechnic State University, USA * Cormac Flanagan, University of California at Santa Cruz, USA * Jurriaan Hage, Utrecht University, NL * Kevin Hammond, University of St. Andrews, UK * Michael Hanus, Christian-Albrechts University zu Kiel, DE * Ralf Hinze, University of Oxford, UK * Zoltan Horvath (PC co-chair), Eotvos Lorand University, HU * Graham Hutton, University of Nottingham, UK * Johan Jeuring, Utrecht University, NL * Pieter Koopman (symp-chair), Radboud University Nijmegen, NL * Hans-Wolfgang Loidl, Ludwig-Maximilians University Munchen, DE * Rita Loogen, Philipps-University Marburg, DE * Greg Michaelson, Heriot-Watt University, UK * Marco T. Morazan, Seton Hall University, USA * Rex L Page, University of Oklahoma, USA * Sven-Bodo Scholz, University of Hertfordshire, UK * Clara Segura, University Complutense de Madrid, ES * Mary Sheeran, Chalmers University of Technology, SE * Phil Trinder, Heriot-Watt University, UK * Marko van Eekelen, Radboud University Nijmegen, NL * Varmo Vene, University of Tartu, EE * Viktoria Zsok (PC co-chair), Eotvos Lorand University, HU LOCATION The Conference Centre of Selye University, Komarno, Slovakia (http://www.selyeuni.sk/) is a new and excellent conference centre with modern equipment, lecture rooms and computer labs. Komarno is on the north bank of river Danube, the northern part of the city Komarom / Komarno. It is a charming old city with about 30 000 inhabitants, 90 km away from Budapest (the capital of Hungary), with good highway and railway connections and 90 km away from Bratislava (the capital of Slovakia), about 100 km from Vienna International Airport. ----------- Call for participation 3rd CENTRAL EUROPEAN FUNCTIONAL PROGRAMMING SCHOOL CEFP 2009 SELYE JANOS UNIVERSITY, KOMARNO, SLOVAKIA May 25-30, 2009 http://www.inf.elte.hu/tfp_cefp_2009 *** The registration is now open! *** The Central European Functional Programming School (CEFP) is organised every second year (2005 Budapest - LNCS vol. 4164, 2007 Cluj-Napoca - LNCS vol. 5161, 2009 Komarno). It is the Central European counterpart of the Advanced Functional Programming school with the additional goal to stimulate students from Central Europe to attend. GOALS * Bring together computer scientists, in particular motivated graduate and PhD students, and make them familiar with the latest functional programming techniques. * Show the use of advanced functional programming techniques in real world applications. * Bridge the gap between recent results presented at programming conferences and material from introductory textbooks on functional programming. * Provide a forum for PhD students to present their research results as part of the workshop programme and submit the full paper version after the summer school. Selected and reviewed papers will be published in the LNCS Volume of the revised lectures. INVITED LECTURERS Our invited lecturers are top experts, professors and researchers from Europe and the US. * Francesco Cesarini: OTP Design Patterns (Erlang Training and Consulting Ltd, London, UK) Francesco Cesarini is owner and founder of Erlang Training and Consulting Ltd, a company specialised in high availability, massively concurrent soft real time systems. * Prof. Rinus Plasmeijer, Pieter Koopman: An effective methodology for defining consistent semantics of complex systems (Radboud University Nijmegen, The Netherlands) Rinus Plasmeijer is chief designer of the functional programming language Clean, member of IFIP WG 2.8., Head of Software Research Group, University Nijmegen, The Netherlands. Currently he is applying advanced functional programming techniques to enable model driven software development. He is working on the iTask system which enables the high-level specification of multi-user workflow systems for the web. Pieter Koopman's research is related to functional programming (especially the Clean language), and specification languages. Currently he is using Clean functions as specifications for the Generic Automatic Software Test-system (Gast). Earlier he was involved in project about parser combinators and implicit surfaces. * Matthew Fluet: Programming in Manticore, a heterogenous parallel language (Toyota Technological Institute at Chicago, USA) Matthew Fluet is active developer of MLton: an open-source, whole-program, optimizing Standard ML compiler. He is collaborating on the development of Manticore: a heterogeneous parallel programming language aimed at general-purpose applications running on multi-core processors. As a programming languages researcher, he is working on the opportunities for mechanizing reasoning about programming languages. * Prof. Ralf Hinze: Reasoning about codata (University of Oxford and Kellogg College, UK) Ralf Hinze's research centers around functional programming, particularly interested in functional algorithm design and purely functional data structures. At the moment he is mainly working on generic functional programming (Generic Haskell). In the past he worked on strictness analysis and type systems. * Prof. Mary Sheeran: Fun with combinators in Haskell (Chalmers University of Technology, Gothenburg, Sweden) Mary Sheeran's research interests are in functional programming, and particularly its application to designing and analysing hardware and hardware-like systems. She has worked on domain specific languages (DSLs) for hardware design (Lava, Wired) and is currently working with Ericsson and ELTE to develop a DSL for Digital Signal Processing. * Prof. John Hughes: QuickCheck, with a focus on industrial applications (http://quviq.com/) Research interests of John Hughes include type systems and formal semantics for programming languages, optimizing compilation, functional programming, and high-level language interoperability. He is currently working in the following projects: Combining Verification Methods in Software Development (Cover) and Flexible System-on-Chip Platforms for Embedded Applications (FlexSoC) * Andrew Kennedy: Advanced type systems for functional programming (Microsoft Research, Cambridge, England) Research interests of Andrew Kennedy include type systems and formal semantics for programming languages, optimizing compilation, functional programming, and high-level language interoperability. * Adam Granicz: Advanced F# Programming Adam Granicz is founder/CEO of Intellifactory Ltd. and he is a co-author of the Expert F# book. His research interests are formal environments and compilers, resource planning, and extensible compilers. PROGRAMME At the beginning of CEFP 2009 we make functional programming warm-up sessions starting on 21 May 2009. The summer school's programme includes: * In depth lectures about a selected number of recently emerged advanced functional programming techniques, taught by experts in the field. * Practical exercises accompanying the lectures to be solved by the students at the school. These exercises guide the students' learning to a great extent. A high quality lab is available at the school site. * Team work is stimulated, such that the students can also learn from each other. CEFP 2009 is co-located with the 10th Symposium on Trends in Functional Programming (TFP 2009, June 2-4), which is held after the summer school. LOCATION The Conference Centre of Selye University, Komarno, Slovakia (http://www.selyeuni.sk/) is a new and excellent conference centre with modern equipment, lecture rooms and computer labs. Komarno is on the north bank of river Danube, the northern part of the city Komarom / Komarno. It is a charming old city with about 30 000 inhabitants, 90 km away from Budapest (the capital of Hungary), with good motorway and railway connections and 90 km away from Bratislava (the capital of Slovakia), about 100 km from Vienna International Airport. ACCOMMODATION * hotels (from 30-66 Euro/night) * meals at the university canteen of the Conference Centre (included in the registration fee) LOCAL ARRANGEMENTS TEAM - CHAIR/CO-CHAIRS OC Chairs: * Zoltan Horvath * Viktoria Zsok (Eotvos Lorand University, Budapest) * Rinus Plasmeijer (Radboud University, Nijmegen) Local Co-chair of OC: * Veronika Stoffa, vice-rector (Selye Janos University, Komarno) Further details can be found at the CEFP website. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090319/b2563027/attachment-0001.htm From v.dijk.bas at gmail.com Thu Mar 19 03:20:01 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Thu Mar 19 03:08:05 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> References: <20090317023944.GN8842@sliver.repetae.net> <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> Message-ID: On Thu, Mar 19, 2009 at 12:16 AM, sylvain wrote: > ... > $ ghc hello.hs -o hello1 > $ jhc hello.hs -o hello2 > $ gcc hello.c -o hello3 > ... How does 'ghc hello.hs -o hello1 -O2' compare? regards, Bas From john at repetae.net Thu Mar 19 04:13:41 2009 From: john at repetae.net (John Meacham) Date: Thu Mar 19 04:01:32 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> References: <20090317023944.GN8842@sliver.repetae.net> <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> Message-ID: <20090319081341.GA11188@sliver.repetae.net> nice, although not quite fair, as jhc always has optimization turned on, so compiling the others with -O is more appropriate. The 'show' instance is clearly eating up most of the time in the jhc version, if you look at the generated C code. here is main as generated by jhc annotated with the haskell it cooresponds to in the comments : static void A_STD ftheMain(void) { // passing in 100000000 to countdown uint32_t v184744394 = 10000000; // countdown :: Int -> IO () fW_a__fMain__fl_aMain__countdown_d43_u8:; { sptr_t v261990436 = ((sptr_t)VALUE(v184744394)); // check if it is zero if (0 == v184744394) { // putStr "finished" fPrelude__IO__putStr(c8); // putChar '\n' return (void)jhc_utf8_putchar((int)10); } else { // let s = show x wptr_t v100000 = fInstance_a__iJhc__Show__show__default(v261990436); sptr_t v118875000 = demote(v100000); // putsStr s fPrelude__IO__putStr(v118875000); // putChar '\n' (void)jhc_utf8_putchar((int)10); // jump to countdown with x = x - 1 uint32_t v14532078 = (v184744394 - 1); v184744394 = v14532078; goto fW_a__fMain__fl_aMain__countdown_d43_u8; } } } John -- John Meacham - ?repetae.net?john? From agocorona at gmail.com Thu Mar 19 10:22:33 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu Mar 19 10:10:25 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <20090317023944.GN8842@sliver.repetae.net> References: <20090317023944.GN8842@sliver.repetae.net> Message-ID: The last version still uses a region inference algoritm instead of a garbage collector?. 2009/3/17 John Meacham > Hi, I am pleased to announce jhc 0.6.0, It has been a long time since an > official release, so there have been a lot of changes. Jhc is an > optimizing haskell compiler that focuses on creating fast and portable > code. Jhc is still mainly of interest to jhc hackers and developers than > the general haskell public, but it is starting to see use in embedded > development with haskell so I decided to make more public announcements > of major releases in the future. > > some links: > > The jhc homepage: > http://repetae.net/computer/jhc/ > > Installation Instructions: > http://repetae.net/computer/jhc/building.shtml > > The jhc manual: > http://repetae.net/computer/jhc/manual.html > > And I am happy to announce, there is now a yum repository* for jhc and my > other projects (such as DrIFT), so if you use an rpm based linux > distribution, you can keep up to date with jhc official releases by > doing: > > ; rpm -i http://repetae.net/yum/repetae-repo-1.0-3.noarch.rpm > ; yum install jhc > > > A couple recent changes: > > jhc now comes bundled with the 'containers' and 'applicative' library > making it much easier to compile many haskell programs out there. > (Data.Graph, Data.IntMap, Data.IntSet, Data.Map, Data.Sequence, > Data.Set, Data.Tree, Control.Applicative, Control.Arrow, > Control.Category, Data.Foldable, Data.Traversable) > > signifigant speed and resource usage improvements in compilation time. > > transparent cross compilation support for creating windows programs on a > unix box. (or iPhone/Nokia Tablet/etc..) > > > If you are interested in jhc development, please sign up on the jhc > mailing list here: http://www.haskell.org/mailman/listinfo/jhc > > John > > * I would love to get proper 'deb's and BSD packages built also > automatically, if anyone wants to help with this, please join the list > and let us know. > > > -- > John Meacham - ?repetae.net?john? > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090319/6105c02a/attachment.htm From sylvain.nahas at googlemail.com Thu Mar 19 16:41:37 2009 From: sylvain.nahas at googlemail.com (sylvain) Date: Thu Mar 19 16:29:30 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <20090319081341.GA11188@sliver.repetae.net> References: <20090317023944.GN8842@sliver.repetae.net> <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> <20090319081341.GA11188@sliver.repetae.net> Message-ID: <1237495297.28674.25.camel@dell.linuxdev.us.dell.com> >so compiling the others with -O is more appropriate. It seems the consensus is I should have activated optimizations. Let check that, same code in the same order (ghc, jhc, gcc). I changed only the options for ghc and gcc. Below is the Makefile, you can double check. with -O 0:09.96 real,9.86 user,0.06 sys 0:02.06 real,1.02 user,0.92 sys 0:02.80 real,2.55 user,0.00 sys with -O2 0:09.81 real,9.70 user,0.07 sys 0:01.95 real,1.01 user,0.93 sys 0:02.57 real,2.56 user,0.00 sys with -O3 0:09.86 real,9.78 user,0.06 sys 0:01.98 real,1.02 user,0.95 sys 0:02.63 real,2.64 user,0.00 sys I have tried with gcc 3.4 and 4.3.2. All results are consistent. Sylvain Nahas Makefile --------------------- OPT:=-O3 CC:=gcc-3.4 CFLAGS:=-Wall $(OPT) JHC:=/home/sylvain/bin/jhc-0.6.0/bin/jhc GHCFLAGS:=$(OPT) TIMEFMT:=-f "%E real,%U user,%S sys" all: test1 test2 test3 .PHONY: test1 test2 test3 test1: hello1 time $(TIMEFMT) ./$^ >/dev/null test2: hello2 time $(TIMEFMT) ./$^ >/dev/null test3: hello3 time $(TIMEFMT) ./$^ >/dev/null hello1: hello.hs ghc $(GHCFLAGS) $^ -o $@ hello2: hello.hs $(JHC) $^ -o $@ hello3: hello.c $(CC) $(CFLAGS) $^ -o $@ clean: -rm hello1 hello2 hello3 hello.hi hello.ho hello_code From colin at colina.demon.co.uk Fri Mar 20 02:22:51 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri Mar 20 02:10:41 2009 Subject: [Haskell] ANNOUNCE: game-tree - a library for searching game trees Message-ID: I've uploaded game-tree 0.1.0.0 to hackage. This library provides a class for dynamic game trees, and purely functional algorithms for searching them. I'm using it in a program that I am writing to play the game of Chu Shogi (see http://www.colina.demon.co.uk/chu.html for a description of the game, not the program). -- Colin Adams Preston Lancashire From nicolas.pouillard at gmail.com Fri Mar 20 14:42:28 2009 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Fri Mar 20 14:31:26 2009 Subject: [Haskell] [ANN] Safe Lazy IO in Haskell Message-ID: <1237574414-sup-7006@ausone.local> Hi folks, We have good news (nevertheless we hope) for all the lazy guys standing there. Since their birth, lazy IOs have been a great way to modularly leverage all the good things we have with *pure*, *lazy*, *Haskell* functions to the real world of files. We are happy to present the safe-lazy-io package [1] that does exactly this and is going to be explained and motivated in the rest of this post. === The context === Although these times were hard with the Lazy/IO technique, some people continue to defend them arguing that all discovered problems about it was not that harmful and that taking care was sufficient. Indeed some issues have been discovered about Lazy/IOs, some have been fixed in the underlying machinery, some have just been hidden and some others are still around. == An alternative == An alternative design has been proposed --and is still evolving--, it is called "Iteratee" [2] and has been designed by Oleg Kiselyov. This new design has tons of advantages over standard imperative IOs, and shares some of the goals of Lazy/IOs. Iteratee provides a way to do incremental processing in a high-level style. Indeed both processed data (via enumerators) and processing code (called iteratee) can be modularly composed. The handling of file-system resources is precise and safe. Catching errors can be done precisely and can be interleaved with the processing. In spite of all this, there is an important drawback: a lot of code has to be re-written and thought in another way. Processing becomes explicitly chunked which is not always needed and, even worse, exceptions handling also becomes very explicit. While this makes sense in a wide range of applications it makes things less natural than the general case of pure functions. We think that Iteratee have too be studied more, and we recommend them when you have incrementally react to IO errors. == Issues of Standard Lazy/IO == We think that we can save Lazy/IO cheaply, but before explaining the way we solve such and such issue, let's first expose Lazy/IO and its issues. One of the main Lazy/IO functions is 'readFile': it takes a file path opens it and returns the list of characters until the end of the file is reached. The characteristic of 'readFile' is that only the opening is done strictly, while the reading is performed lazily as much as the output list is processed. Cousins of 'readFile' are 'hGetContents' that takes a file handle and 'getContents' that reads on the standard input. This technique enables to process a file as if the file was completely stored in memory. Because it is read lazily one knows that only the required part of the file will be read. Even better, if the input is consumed to produce a small output or the output is emitted incrementally, then the processing can be done in constant memory space. Examples: -- Prints the number of words read on stdin > countWords = print . length . words =<< getContents -- Prints the length of the longest line > maxLineLen = print . maximum . map length . lines =<< getContents -- Prints in lower case the text read on stdin > lowerText = interact (map toLower) -- Alternatively > lowerText = putStr . map toLower =<< getContents All these examples are pretty idiomatic Haskell code and make a simple use of Lazy/IOs. Each of them runs in constant memory space even if they are declared as if the whole contents were available at once. By using stream fusion or 'ByteString''s one can get even faster code while keeping the code almost the same. Here we will stay with the default list of 'Char''s data type. However one goal of our approach is to be trivially adaptable to those data types. Using our library will be rougly a matter of namespace switch plus a running function: > lowerText = LI.run' (SIO.putStr . map toLower <$> LI.getContents) However we will introducing this library as one goes along. Here is another example where the Lazy/IO are still easy to use but no longer scales well. This program counts the lines of all the files given in arguments: > countLines = print . length . lines . concat =<< mapM readFile =<< getArgs Here the problem is the limitation of simultaneous opened files. Indeed, all the files are opened at the beginning therefore reaching the limit easily. It's time to recall when the files are closed. With standard Lazy/IOs the handle is closed when you reach the end of the file, and so when you've explored the whole list returned by 'readFile'. Note also that if you manually open the file and get a handle, then you can manually close the file, however if by misfortune you close the file and then still consume the lazy list you will get a truncated list, observing how much of the file has been read. This last point is due to the fact that 'readFile' considers the reading error as the end of the file. In particular one can fix this program, by simply counting the number of lines of each file separately and then compute the sum to get the final result. > countLines = print . sum =<< mapM (fmap (length . lines) . readFile) =<< getArgs However once again this program exhausts the handle resources. Trying to close the files will not save us either, one just risks getting truncated files. Indeed the list of intermediate results is produced eagerly but each intermediate result is lazy and then each file is opened but not immediately closed since the computation is delayed. Hopefully adding a bit of strictness cures the problem: > countLines = print . sum =<< mapM ((return' . length . lines =<<) . readFile) =<< getArgs > where return' x = x `seq` return x Until there, we have disclosed three problems: * while reading is lazy, opening is strict, which leads to a less natural processing of multiple files * the closing of files is hard to predict * the errors during reading are silently discarded The last one is a bit trickier and has recently been exposed by Oleg Kiselyov [3]. The problem appears when one gets twice the contents of the same stream---or some kind of inter-dependent streams. Because reading is implicitly driven by the consumer, the interleaving of reading may then depend on the reduction strategy employed. This is the case even if the consumer is a pure function. Basically in this example one can observe different values when using one of these functions: > f1 x y = x `seq` y `seq` x - y > f2 x y = y `seq` x `seq` x - y In this example one reads stdin twice and relies on the error handling to end one stream while keeping the other opened. Moreover there are other ways to achieve this like the use of unix fifo files, or using 'getChanContents' from the "Control.Concurrent.Chan" module. === Our solution === Here we will present another design, based on a very simple idea. Our goal is to provide IO processing in a style very similar to standard Lazy/IO with the following differences: - preservation of the determinism; - a simple control exceptions; - and a precise management of resources. Our solution is made of three key ingredients: a bit of strictness, some predefined schemas to interleave inputs, some scopes and abstract types to delimit lazy input operations from strict IO operations. == Dealing with a single input == Let's present the first ingredient alone through a first example: > mapHandleContents :: NFData sa => Handle -> (String -> sa) -> IO sa > mapHandleContents h f = do > s <- hGetContents h > return' (f s) `finally` hClose h > return' :: (Monad m, NFData sa) => sa -> m sa > return' x = rnf x `seq` return x It implements some combination of 'fmap' and 'hGetContents'. Actually some of our examples fit nicely in that model: > countWords = print =<< mapHandleContents stdin (length . words) > maxLineLen = print =<< mapHandleContents stdin (maximum . map length . lines) > lowerText = putStr =<< mapHandleContents stdin (map toLower) However while the two first examples work well in this setting, the third one tries to allocate the whole result in memory before printing it. Here the ingredient that is used is strictness: the purpose in forcing the result is to be sure that all the needed input is read, before the file is closed. So here we rely on 'NFData' instances to really perform deep forcing---this kind of assumption is a bit like 'Typeable' instances. In particular functions must not be an instance of 'NFData': indeed, we have no way to force lazy values that are stored in the closure of a function. The same remark applies to the 'IO' monad for at least three reasons: 'IO' if often represented by functions; lazy 'IORef''s could be used to hide one input for later use; exceptions with a lazy contents could also be used to make a lazy value escape. Let's now add some more strictness into the meal: the 'SIO' monad! == The 'SIO' monad == The 'SIO' monad is a thin layer over the 'IO' monad, populated only by strict 'IO' operations. In particular these operations are strict in the output, which means that once the output is produced then we know that the given arguments cannot be further evaluated/forced. Here is an example of strict IO using the 'SIO' monad: > import qualified System.IO.Strict as SIO > import System.IO.Strict (SIO) > countWords = SIO.run (SIO.print . length . words =<< SIO.getContents) Of course this function does not scale well since it reads the whole contents in memory before processing it. For now the strict-io [4] package contains wrappers for functions in "System.IO", and strict 'IORef''s. One can now introduce a function in lines of 'mapHandleContents': > withHandleContents :: NFData sa => Handle -> (String -> SIO sa) -> IO sa > withHandleContents h f = do > s <- hGetContents h > SIO.run (f s) `finally` hClose h One can then rewrite 'lowerText' as follow: > lowerText = withHandleContents stdin (SIO.putStr . map toLower) Until there one can deal quite nicely with single input, many outputs processing. Currently the only requirement is to delimit a scope where the resource will be used to return a strict value. Dealing with multiple inputs will lead us to our final design of lazy inputs. == Introducing 'LI', Lazy Inputs == We first introduce a type for these lazy inputs namely 'LI'. This type is abstract and we will progressively introduce functions to build, combine and run them. The 'LI' type is a pointed functor, but not necessarily a monad nor an applicative functor. Therefore one exports the 'pure' function as 'pureLI'. Building primitives allow to read files or handles: > LI.pureLI :: a -> LI a > LI.hGetContents :: Handle -> LI String > LI.getContents :: LI String > LI.readFile :: FilePath -> LI String > LI.getChanContents :: Chan a -> LI [a] Being a functor is important: it allows to wholly transform the underlying input lazily using standard functions about lists for instance: > length <$> LI.readFile "foo" > words <$> LI.readFile "foo" Extracting a final value of a lazy input ('LI' type) is a matter of using: > LI.run :: (NFData sa) => LI sa -> IO sa Or > LI.run' :: (NFData sa) => LI (SIO a) -> IO sa One can therefore re-write our examples using lazy inputs: > -- embedded printing > countWords = LI.run' (SIO.print . length . words <$> LI.getContents) > -- external printing > maxLineLen = print =<< LI.run (maximum . map length . lines <$> LI.getContents) > lowerText = LI.run' (SIO.putStr . map toLower <$> LI.getContents) == Combining inputs == Finally we come to managing multiple inputs. To get both laziness and precise resource management we will provide dedicated combinators. The first one is as simple as appending. > LI.append :: NFData sa => LI [sa] -> LI [sa] -> LI [sa] This one produces a single stream out that sequences the two given streams. It also sequences the usage of resources: the first resource is closed and then the second one is opened. Note that this combinator is still quite general since one can process each input beforehand: > -- one can drop parts of the inputs > (take 100 <$> i1) `LI.append` (drop 100 <$> i2) > -- one can tag each input to know where they come from > Left <$> i1 `LI.append` Right <$> i2 The second one is 'LI.zipWith' which opens the two resources and joins the items into a single stream. Again, since 'LI' is a functor one can join not only characters but also words, lines, chunks... A problem with zipping is that it stops on the shorter input (loosing a part of the other), hopefully one can prolongate them: > zipMaybesWith :: (NFData sa, NFData sb) -> (Maybe sa -> Maybe sb -> c) -> LI [sa] -> LI [sb] -> LI [c] > zipMaybesWith f xs ys = > map (uncurry f) . takeWhile someJust <$> zip (prolongate <$> xs) (prolongate <$> ys) > where someJust (Nothing, Nothing) = False > someJust _ = True > prolongate :: [a] -> [Maybe a] > prolongate zs = map Just zs ++ repeat Nothing The last one is 'LI.interleave': > LI.interleave :: (NFData sa) -> LI [sa] -> LI [sa] -> LI [sa] This function is currently left biased, moreover each resource is closed as soon as we reach its end. However since the inputs are mixed up together one generally prefers a tagged version trivially build upon this one: > interleaveEither :: (NFData sa, NFData sb) => LI [sa] -> LI [sb] -> LI [Either sa sb] > interleaveEither a b = interleave (map Left <$> a) (map Right <$> b) Here are some final programs that scale well with the number of files. > -- number of words in the given files > main = print =<< LI.run . fmap (length . words) . LI.concat . map LI.readFile =<< getArgs > -- almost the same thing but counts words independently in each file > main = print > =<< LI.run . fmap sum . LI.sequence . map (fmap (length . words) . LI.readFile) > =<< getArgs > -- prints to stdout swap-cased concatenation of all input files > main = LI.run' . (fmap (SIO.putStr . fmap swapCase) . LI.concat . map LI.readFile) =<< getArgs > where swapCase c | isUpper c = toLower c > | otherwise = toUpper c > -- sums character code points of inputs > main = print =<< LI.run . fmap (sum . map (toInteger . ord)) . LI.concat . map LI.readFile =<< getArgs Our solution is from now widely available as an Hackage package named "safe-lazy-io" [4]. We hope you will freely enjoy using Lazy/IO again! As usual, criticisms, comments, and help are expected! Finally, I would like to thank Benoit Montagu and Francois Pottier for helping me out to polish this work! [1]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/safe-lazy-io [2]: http://okmij.org/ftp/Streams.html [3]: http://www.haskell.org/pipermail/haskell/2009-March/021064.html [4]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/strict-io -- Nicolas Pouillard From ardubois at gmail.com Sat Mar 21 03:58:26 2009 From: ardubois at gmail.com (Andre Rauber Du Bois) Date: Sat Mar 21 03:46:13 2009 Subject: [Haskell] Call For Papers: SBLP 2009 In-Reply-To: <92aea2e20903210056x2778d571kce52cc166effb07d@mail.gmail.com> References: <92aea2e20903210056x2778d571kce52cc166effb07d@mail.gmail.com> Message-ID: <3ab4946a0903210058gb784936m265310b97789fa01@mail.gmail.com> 13th BRAZILIAN SYMPOSIUM ON PROGRAMMING LANGUAGES http://sblp2009.ucpel.tche.br Gramado, Rio Grande do Sul, Brazil August 19-21, 2009 Abstract Submission: April, 6 Paper Submission: April, 13 SBLP is a *Qualis A* Brazilian Conference CALL FOR PAPERS AND TUTORIALS The 13th Brazilian Symposium on Programming Languages, SBLP 2009, will be held in Gramado, Rio Grande do Sul, Brazil, on August 19-21, 2008. SBLP provides a venue for researchers and practitioners interested in the fundamental principles and innovations in the design and implementation of programming languages and systems. This year the symposium will be co-located with the Brazilian Symposium on Formal Methods, which will happen in the same week and in the same venue. SBLP 2009 invites authors to contribute with Technical Papers and Tutorial Proposals related (but not limited) to: * Programming language design and implementation * Formal semantics of programming languages * Theoretical foundations of programming languages * Design and implementation of programming language environments * Object-oriented programming languages * Functional programming * Aspect-oriented programming languages * Scripting languages * Domain-specific languages * Programming languages for mobile, web and network computing * New programming models * Program transformations * Program analysis and verification * Compilation and interpretation techniques Contributions can be written in Portuguese or English. Papers should have at most 14 pages. All accepted papers will be published in the conference proceedings. Selected papers written in English should be invited for a journal publication. Papers should be presented in the language of submission. Tutorial submissions must be in the form of an extended abstract with at most 10 pages. The final version of accepted tutorials should contain at most 30 pages. This final version will be distributed to attendees. An abstract of the tutorial (1-2 pages) will be included in the conference proceedings. Detailed submission guidelines will be available at http://sblp2009.ucpel.tche.br IMPORTANT DATES Paper abstract submission (15 lines): April 6, 2009 Full paper submission: April 13, 2009 Notification of acceptance: June 8, 2009 Final papers due: June 30, 2009 BEST PAPER AWARD Awards will be given for the best papers at the symposium. GENERAL CHAIR Andre Rauber Du Bois, UCPel PROGRAMME CHAIRS Andre Santos, UFPE, Brazil Joao Saraiva, Universidade do Minho, Portugal PROGRAMME COMMITTEE Alberto Pardo, Univ. de La Republica Alex Garcia, IME Alfio Martini, PUC-RS Alvaro Freitas Moreira, UFRGS Andre Rauber Du Bois, UCPel Carlos Camarao, UFMG Christiano Braga, Univ. Comp. de Madrid Cristiano Damiani, UFPEL Edward Hermann Haeusler, PUC-Rio Eric Tanter, Univ. of Chile Fernando Castor Filho, UFPE Francisco Heron de Carvalho Junior, UFC Isabel Cafezeiro, UFF Johan Jeuring, Utrecht Univ. Jose Guimaraes, UFSCAR Jose E. Labra Gayo, Univ. of Oviedo Jose Luiz Fiadeiro, Univ. of Leicester Lucilia Figueiredo, UFOP Luis Soares Barbosa, Univ. do Minho Luis Carlos Meneses, UPE Marcelo A. Maia, UFU Marco Tulio Valente, PUC Minas Mariza A. S. Bigonha, UFMG Martin A. Musicante, UFRN Noemi Rodriguez, PUC-Rio Paulo Borba, UFPE Peter Mosses, Swansea University Rafael Dueire Lins, UFPE Renato Cerqueira, PUC-Rio Ricardo Massa Lima, UFPE Roberto S. Bigonha, UFMG Roberto Ierusalimschy, PUC-Rio Rodolfo Jardim de Azevedo, UNICAMP Sandro Rigo, UNICAMP Sergio de Mello Schneider, UFU Sergio Soares, UFRPE Sergiu Dascalu, Univ. of Nevada Simon Thompson, Univ. of Kent Varmo Vene, Univ. de Tartu Vladimir Di Iorio, UFV Vitor Santos Costa, UFRJ ORGANIZATION Brazilian Computer Society and Universidade Catolica de Pelotas From byorgey at seas.upenn.edu Sat Mar 21 10:01:02 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Mar 21 09:48:58 2009 Subject: [Haskell] Haskell Weekly News: Issue 110 - March 21, 2009 Message-ID: <20090321140102.GA20963@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090321 Issue 110 - March 21, 2009 --------------------------------------------------------------------------- Welcome to issue 110 of HWN, a newsletter covering developments in the [1]Haskell community. [2]Facebook apps with Happstack, [3]Sudoku with Cryptol, what next? Tic-tac-toe with darcs? Anyway, lots of neat stuff this week, including new releases of [4]GHC, [5]jhc, and the [6]Monad.Reader, some [7]fun [8]visualizations, and more. Also, students: apply to work on a [9]Haskell project for the Google Summer of Code! Announcements GHC 6.10.2 Release Candidate 1. Ian Lynagh [10]announced the [11]first release candidate for GHC 6.10.2. Please test as much as possible; bugs are much cheaper if we find them before the release! jhc 0.6.0 Haskell Compiler. John Meacham [12]announced the release of [13]jhc 0.6.0. Safe Lazy IO in Haskell. Nicolas Pouillard [14]announced the [15]safe-lazy-io package that provides special types and combinators for performing safe lazy I/O. game-tree - a library for searching game trees. Colin Paul Adams [16]announced [17]game-tree 0.1.0.0, which provides a class for dynamic game trees, and purely functional algorithms for searching them. random-shuffle package. Manlio Perillo [18]announced the availability of the [19]random-shuffle package, which is based on [20]Oleg's description. random-stream package. Manlio Perillo [21]announced the [22]random-stream package, which provides a portable interface for the operating system source of pseudo random data. Supported sources are Unix /dev/urandom, Win32 CryptGenRandom and OpenSSL pseudo random numbers generator. language-python. Bernie Pope [23]announced the [24]language-python package, which provides a parser (and lexer) for Python, written in Haskell. Currently it only supports version 3 of Python (the most recent version), but it will support version 2 in the future. Google Summer of Code. Malcolm Wallace [25]announced that haskell.org has once again been accepted as a mentoring organisation for the 2009 Google Summer of Code. Student applications open on Monday (23rd March) at 1900 UTC, for a period of 12 days (until Fri 3rd April, also at 1900 UTC). Students applicants are encouraged to interact with the community via mailing lists, prior, during, and after the submission of their ideas for projects. Because (sadly) the darcs community did not get accepted as a separate organisation this year, haskell.org will be willing to accept proposals relating to darcs. regex-tdfa-1.1.0. ChrisK [26]announced the release of [27]regex-tdfa-1.1.0. This version is a small performance update to the old regex-tdfa-1.0.0 version. Previously all text (e.g. ByteString) being search was converted to String and sent through a single engine; the new version uses a type class and SPECIALIZE pragmas to avoid converting to String. This should make adding support for searching other Char containers easy to do. Haskell on your system? Information wanted!. Don Stewart [28]announced that haskell.org now features links to wiki pages explaining how to obtain Haskell on windows, mac osx and linux and bsd. If you're a distro maintainer for these systems, please consider adding relevant pointers to the pages, so that users of these systems can find all the info they need. libffi 0.1 released. Remi Turk [29]announced the release of [30]libffi 0.1, bindings to the C library libffi, allowing C functions to be called whose types are not known before run-time. Haskell Logo Voting has started!. Eelco Lempsink [31]announced that voting has begun to choose the new Haskell logo. All subscribed to haskell-cafe should have received a ballot; if you are not directly subscribed, you can still send ballot requests until the end of the competition (March 24, 12:00 UTC). Make sure the message contains 'haskell logo voting ballot request' in the subject. A long discussion of what color to paint the bike shed and why this particular bike shed will not do for storing bikes ensued. The Monad.Reader (13). Wouter Swierstra [32]announced that a new issue of [33]The Monad.Reader, a quarterly magazine about functional programming, is now available. Issue 13 consists of the following four articles: "Rapid Prototyping in TEX" by Stephen Hicks; "The Typeclassopedia" by Brent Yorgey; a Real World Haskell book review by Chris Eidhof and Eelco Lempsink; and "Calculating Monads with Category Theory" by Derek Elkins. dzen-utils 0.1. Felipe Lessa [34]announced the release of [35]dzen-utils 0.1, which contains various utilities for creating dzen input strings in a type-safe way using some combinators, including the ability to apply colors locally (instead of applying for everything beyond some point). It can also emulate dbar and gdbar, do automatic padding, and more. Discussion transformers versus mtl. Ganesh Sittampalam began a [36]discussion on the relative status of the 'transformers' and 'mtl' packages. least fixed points above something. Jens Blanck [37]asked about a function to compute fixed points starting from a seed value (as opposed to computing the least defined fixed point). Type equality proof. Martijn van Steenbergen [38]requested feedback on a proposed module collecting utilities for working with type equality proofs. What unsafeInterleaveIO is unsafe. Yusaku Hashimoto began a [39]discussion by asking why unsafeInterleaveIO is considered unsafe, or under what circumstances its use can be considered safe. Jobs How do students learn Haskell? Postgraduate project at University of Kent. S.J.Thompson [40]announced that funding is available for a [41]postgraduate project to study how students learn Haskell, based on the wealth of data collected through the instrumented version of the [42]Helium system for Haskell. The project will be supervised by Simon Thompson and Sally Fincher, in collaboration with Jurriaan Hage, Utrecht University. Blog noise [43]Haskell news from the [44]blogosphere. * Neil Mitchell: [45]Concise Generic Queries. Neil compares solving a query problem with several different generic programming libraries. * Jeff Heard: [46]Preview: Data Waves. A neat new type of data visualization, built using Hieroglyph. * >>> necrobious: [47]A fun example of Haskell's newtype. * GHC / OpenSPARC Project: [48]Peak issue rate is 18.64 Gig instrs/sec. * happstack.com: [49]Jeremy Shaw creates first Facebook App with Happstack. * GHC / OpenSPARC Project: [50]Peak performance. * Galois, Inc: [51]Solving Sudoku Using Cryptol. * Xmonad: [52]xmonad on ubuntu. A tutorial on getting started with xmonad on Ubuntu. * Don Stewart (dons): [53]Visualising the Haskell Universe. Pretty dependency graphs of ten thousand Haskell modules! * >>> Sean Chapel: [54]Haskell. * >>> Dean Berris: [55]The Haskell Experiment: HaskellDB, HTTP, and Monads. * Holumbus: [56]Hayoo! Update. The Hayoo! package index has been updated to include everything currently on Hackage! * >>> John Wiegley: [57]Journey into Haskell, Part 1. John ventures down the rabbit hole. * Bjorn Buckwalter: [58]Blogging with Pandoc, literate Haskell, and a bug. * Bjorn Buckwalter: [59]Extended sessions with the Haskell Curl bindings. * Brent Yorgey: [60]Monad.Reader #13 is out!. * Manuel M T Chakravarty: [61]Final version of "GPU Kernels as Data-Parallel Array Computations in Haskell".. * Xmonad: [62]Visualising xmonad. * Darcs: [63]darcs weekly news #21. * mightybyte: [64]Transactional Integrity Problem. * >>> Dean Berris: [65]The Haskell Experiment: Learning a New Programming Language. * >>> John Wiegley: [66]Hello Haskell, Goodbye Lisp. Quotes of the Week * ray: three dimensional zippers make my scalp hurt when i get my hair caught in them * dolio: [regarding a paypal spam message on #haskell] Take that, Harrop! Does OCaml have illegal cracking utilities? * lament: I think I speak for everyone in this channel when I say haskell is absolutely horrible and nobody would ever want to use it * MiguelMitrofanov: The first glimpse of this [logo] vote scared me so much that I've closed the page, stopped the browser, and shut my computer down. * osfameron: can I store gtk2hs-Buttons in a datastructure? ImInYourMonad: I think you have to sew them on with gtk2hs-Thread * chrisdone: I think you mean Peyton `Simon` Jones. About the Haskell Weekly News New editions are posted to [67]the Haskell mailing list as well as to [68]the Haskell Sequence and [69]Planet Haskell. [70]RSS is also available, and headlines appear on [71]haskell.org. To help create new editions of this newsletter, please see the information on [72]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [73]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://blog.happstack.com/2009/03/18/jeremy-shaw-creates-first-facebook-app-with-happstack/ 3. http://www.galois.com/blog/2009/03/18/solving-sudoku-using-cryptol/ 4. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/16506 5. http://www.haskell.org//pipermail/haskell/2009-March/021116.html 6. http://www.haskell.org/haskellwiki/The_Monad.Reader 7. http://vis.renci.org/jeff/2009/03/20/preview-data-waves/ 8. http://donsbot.wordpress.com/2009/03/16/visualising-the-haskell-universe/ 9. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55109 10. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/16506 11. http://www.haskell.org/ghc/dist/6.10.2-rc1/ 12. http://www.haskell.org//pipermail/haskell/2009-March/021116.html 13. http://repetae.net/computer/jhc/ 14. http://article.gmane.org/gmane.comp.lang.haskell.general/16977 15. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/safe%2Dlazy%2Dio 16. http://article.gmane.org/gmane.comp.lang.haskell.general/16976 17. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/game%2Dtree 18. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55159 19. http://haskell.mperillo.ath.cx/random-shuffle-0.0.2.tar.gz 20. http://okmij.org/ftp/Haskell/perfect-shuffle.txt 21. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55143 22. http://haskell.mperillo.ath.cx/random-stream-0.0.1.tar.gz 23. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55116 24. http://projects.haskell.org/language-python/ 25. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55109 26. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55073 27. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex%2Dtdfa 28. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55036 29. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54959 30. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/libffi 31. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54958 32. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54880 33. http://www.haskell.org/haskellwiki/The_Monad.Reader 34. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54835 35. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dzen-utils 36. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/10807 37. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/55132 38. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/54946 39. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/54840 40. http://article.gmane.org/gmane.comp.lang.haskell.general/16967 41. http://www.cs.kent.ac.uk/research/pg/ 42. http://www.cs.uu.nl/wiki/Helium 43. http://planet.haskell.org/ 44. http://haskell.org/haskellwiki/Blog_articles 45. http://neilmitchell.blogspot.com/2009/03/concise-generic-queries.html 46. http://vis.renci.org/jeff/2009/03/20/preview-data-waves/ 47. http://necrobious.blogspot.com/2009/03/fun-example-of-haskells-newtype.html 48. http://ghcsparc.blogspot.com/2009/03/peak-issue-rate-is-1864-gig-instrssec.html 49. http://blog.happstack.com/2009/03/18/jeremy-shaw-creates-first-facebook-app-with-happstack/ 50. http://ghcsparc.blogspot.com/2009/03/peak-performance.html 51. http://www.galois.com/blog/2009/03/18/solving-sudoku-using-cryptol/ 52. http://xmonad.wordpress.com/2009/03/18/xmonad-on-ubuntu/ 53. http://donsbot.wordpress.com/2009/03/16/visualising-the-haskell-universe/ 54. http://seanchapel.blogspot.com/2009/03/haskell.html 55. http://www.deanberris.com/mental-blabberings/2009/3/17/the-haskell-experiment-haskelldb-http-and-monads.html 56. http://holumbus.fh-wedel.de/blog/?p=19 57. http://www.newartisans.com/2009/03/journey-into-haskell-part-1.html 58. http://flygdynamikern.blogspot.com/2009/03/blogging-with-pandoc-literate-haskell.html 59. http://flygdynamikern.blogspot.com/2009/03/extended-sessions-with-haskell-curl.html 60. http://byorgey.wordpress.com/2009/03/16/monadreader-13-is-out/ 61. http://justtesting.org/post/86905420 62. http://xmonad.wordpress.com/2009/03/16/visualising-xmonad/ 63. http://blog.darcs.net/2009/03/darcs-weekly-news-21.html 64. http://softwaresimply.blogspot.com/2008/02/transactional-integrity-problem.html 65. http://www.deanberris.com/mental-blabberings/2009/3/14/the-haskell-experiment-learning-a-new-programming-language.html 66. http://www.newartisans.com/2009/03/hello-haskell-goodbye-lisp.html 67. http://www.haskell.org/mailman/listinfo/haskell 68. http://sequence.complete.org/ 69. http://planet.haskell.org/ 70. http://sequence.complete.org/node/feed 71. http://haskell.org/ 72. http://haskell.org/haskellwiki/HWN 73. http://code.haskell.org/~byorgey/code/hwn/ From batterseapower at hotmail.com Sat Mar 21 12:30:37 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sat Mar 21 12:18:41 2009 Subject: [Haskell] [ANN] ansi-terminal, ansi-wl-pprint - ANSI terminal support for Haskell Message-ID: <9d4d38820903210930x14c6ef9ai7b5681c2f74ee15b@mail.gmail.com> These two packages allow Haskell programs to produce much richer console output by allowing colorisation, emboldening and so on. Both Unix-like (OS X, Linux) and Windows operating systems are supported (via a pure Haskell ANSI emulation layer for Windows). Examples, screenshots, and lots more information about how to get the packages are available at the freshly-minted homepages: http://batterseapower.github.com/ansi-terminal/ http://batterseapower.github.com/ansi-wl-pprint/ These two packages have actually been in stealth release mode on Hackage for some time. However, they seem to be getting some use and I'm not getting any bug reports, so I figure that they /must/ be stable enough to make a proper announcement :-) Cheers, Max (p.s: the GitHub "pages" feature seems to be absolutely ace - highly reccomended! http://pages.github.com/) From David.von.Oheimb at siemens.com Fri Mar 20 14:51:22 2009 From: David.von.Oheimb at siemens.com (David von Oheimb) Date: Sat Mar 21 12:33:51 2009 Subject: [Haskell] Re: Formal verification of high-level language implementation of critical software? In-Reply-To: <49900A24.6040509@siemens.com> References: <49900A24.6040509@siemens.com> Message-ID: <49C3E5AA.2030809@siemens.com> Hello, thanks again to all who have responded to the request I sent on Feb 9. We got a couple of really good pointers and inspiring discussions. As requested by Bruce Watson, below I reproduce them for he benefit of all. Cheers, David Prof.Dr. Bruce W. Watson wrote: > Hi David, I'm sorry to say that I don't have the answers for you, > but coming from Eindhoven, I'm also hoping that someone will a good > response to you. If they do, will you summarize for this group? > Thanks and best regards to you, Bruce. *********************************************************************** Jan J?rjens wrote: > Hi again, > > you should have a look at Andy's work using F-sharp if you don't already know it. > > Jan Andy Gordon (MSR) wrote: > Hi David, > > The work Jan is referring to involved a suite of verification tools for F# Inserted by DvO: http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/default.aspx > programs called the CVK (Crypto Verification Kit). > See http://research.microsoft.com/cvk for an overview. > We have done formal verification of self-written F# programs for the CardSpace and TLS protocols, for example. The paper on CardSpace is here. > http://research.microsoft.com/en-us/um/people/adg/Publications/details.htm#wcf-cardspace > The TLS implementation is here: > http://www.msr-inria.inria.fr/projects/sec/fs2cv/tlsimpl.pdf > > Regards, > > Andy *********************************************************************** John Matthews wrote: > Hi David, > > You posted a question a month back on the Haskell mailing list about > whether any software components have been written in a high level > language that have also been formally verified. I can think of a few: > > * There have been lots of software programs written in ACL2's first > order logic, which also happens to be a subset of Common Lisp. > > * NICTA's L4.Verified project uses Haskell to write an executable high > level model of their L4 microkernel. But they end up writing the actual > application in C and proving refinement, so that may not be what you are > looking for. > > * At Galois we have developed a domain specific functional language > called Cryptol for specifying cryptographic algorithms like DES and AES. > Cryptol is a purely functional language with compilers for VHDL, C, and > Haskell. Cryptol also comes with formal methods tools, including a a > MiniSat-based equivalence checker, a translator to Berkeley's ABC > equivalence checker, and a prototype translator to Isabelle. You can > find out more about Cryptol here: > > http://www.cryptol.net > > * We also developed a small monadic imperative language in Isabelle/HOL > for writing a security-critical cross-domain disk block access > controller. We proved safety and data separation properties about the > controller, and in fact the data separation proof method was inspired in > part by your ESORICS 2004 paper! inserted by DvO: http://david.von-oheimb.de/cs/papers/Noninfluence.html > We then wrote a simple translator from our monadic Isabelle/HOL subset to C. > > My colleague Paul Graunke actually carried out the work on this project, > I mainly acted as an Isabelle/HOL consultant. Paul published an experience > report at the System Software Verification workshop (SSV'08), titled > "Verified Safety and Information Flow of a Block Device". > > > * Levent Erkok and I wrote a joint paper with Alex Krauss, Florian > Haftmann, and Lukas Bulwahn in TPHOLs 2008 titled "Imperative Functional > Programming in Isabelle/HOL", inserted by DvO: http://web.cecs.pdx.edu/~jmatthew/papers/TPHOLs08.pdf > where we showed how to model a > Haskell-style state monad with first-class polymorphic heap references > and mutable arrays. Isabelle can then generate efficient imperative > Haskell, SML, and OCaml code for programs written in this monad. The > case studies include an efficient SAT checker and an imperative bytecode > verifier for Jinja, both of which were verified. [...] > > All the best, > -john *********************************************************************** Eric Verhulst wrote: > > Dear Mr. Oheimb, > > I am not really surprised about this observation. Higher level languages > provide more abstraction and most programming errors are due to the > nitty-gritty details of the implementation. When using a language like C, > one should be aware that the language is basically a form of a higher level > assembler exposing the hardware to the program. In addition, it has a > "dirty" syntax resulting in about 14O MISRA rules + 50 non-documented ones. > Why not change the language instead? > > But performance is often the issue and hence C is often used. Small code > size also means less power and less dead code, the latter also being safety > and security issues. In my personal view, it is hence a fallacy to say that > higher level languages are the solution. HLL contribute but a clean and > hence simple semantic model and a clean syntax are probably of higher > interest than a high level language that carries too much complexity and > overhead. > > Our own experience developing a network centric RTOS using formal modeling > also proved that the architecture is an important factor that is often > overlooked. While the initial set-up was to use formal modeling mainly for > verifying the software, it was used from the beginning for developing the > architecture and the functionality. The result was a big surprise. While the > team had more than ten years experience developing a similar RTOS in the > traditional way, the resulting architecture was much more straightforward > and clean, resulting in a code size that was 5 to 1O times smaller. The > architecture was also much safer (no risk of buffer overflow) and much more > scalable. The initial design phase took about 18 months but we had running > code in just 2 weeks. Later on, most issues were related to hardware issues > e.g. when developing drivers. > > My personal view is that for software like an RTOS, high level languages are > not really suitable. But for application I believe that code writing should > be avoided at all cost by using code generators that start from user defined > models, eventually complemented by formal provers (although it is early days > for such tools). An example is Matlab/simulink, at least in the domain of > e.g. algorithms. Another promising approach is to use languages (like B) > that allow incremental refinement with formal model checking in parallel. > Once such a design is complete, the risk of introducing errors even when > recoding into C is much lower than when writing by hand. > Hence, we should see these modeling tools like HLL. Nevertheless, for > educational purposes, such HLLs should be used a lot more often as they help > to learn to think in an abstract way (while most software engineers are > immediately influenced by their prior implementations and patterns.) Once > they master this, they will also write better programs in C. > > For more information about the project see www.altreonic.com and > www.openlicensesociety.org. The product is called OpenComRTOS. > > Best regards, > > Eric Verhulst *********************************************************************** Gerwin Klein wrote [translated]: > our seL4 kernel of course! It is written in Haskell and verified, > then re-implemented in C, optimized, and verified (the latter is > not yet finished, but just 6-7 weeks to go). I responded: Cool! Having a look at the picture and description at http://ertos.org/research/l4.verified/ is seems that the verification relation between the Haskell prototype and the actual code is not the usual one, where one would have (security/access control) objectives, against to which one verifies the HLD, against to which one verifies the LLD which is the Haskell implementation, against to which one verifies the optimized C implementation, right? Why did you use at the LLD level an automatically translated C version of the Haskell prototype? Gerwin Klein responded: > Greg Kimberly wrote: >> L4.verified does look interesting. >> >> Is the reason that Haskell version is not part of the proof chain because >> the "Automatic Translation" from Haskell to C is problematic from a proof >> perspective? > > The translation from Haskell to C in this case is not automatic, the C code is > completely hand-written. It follows the structure of the Haskell code closely, > but it is hand-optimised and very close to the bare metal. It is a real, > high-performance microkernel, competitive in performance with L4::Pistachio > and the current commercial OKL4 releases on ARM by Open Kernel Labs. > These are the fastest microkernels in the world. > > Greg Kimberly wrote: >> If that's the case, what would it take to fix that? > > Having completed about 60% of the C proofs, we think, we might have been able to generate "boring" parts of the C kernel from Haskell, but for this extremely performance-critical application, there will always be a lot of manual tweaking involved, so it is unclear if we could get rid of this step usefully. > > Some parts of the current kernel (packed bitfield data structures in tagged unions) are automatically generated, with automatically generated implementation proofs, but not from Haskell directly. The data structures have their own specification language specifying hardware layout etc. This technique is used in other L4 kernels as well (without the proofs), because implementers don't trust the compiler to get packed bitfields right. > > It turns out, though, that the Haskell <-> C proof is the smallest of the big proof steps in this project. We were careful to shift all deep semantic reasoning to the upper level so that really only syntactic reasoning and optimisations remain. > > If the application is not a microkernel, but an application on top of a microkernel, the picture might look quite different. Depending on how large a trusted computing base your are willing to live with, you could run Haskell directly on seL4 (we have a project going on that ports Haskell to bare seL4). You would still have the Haskell compiler and runtime in the TCB, but we think that Haskell is good for application level programming. That means you would only be proving things on the Haskell level, not on C. Much more convenient and efficient. > > I believe the guys from Galois Inc in the US (John Matthews et al) might have similar views on this. Gerwin Klein responded: > (see also other email). The C version is not automatically translated, it is carefully hand-crafted. In this project, we see the Haskell prototype as an executable specification. The performance difference is enormous (we never intended the Haskell prototype to be fast, so no thought whatsoever went into optimising it). > > David von Oheimb wrote: >> Good to hear that at least for the application level you believe a >> relatively easily verifiable HLL implementation is efficient enough. >> >> No doubt that the translation to the lowest level (down from the LLD) is >> manual for efficiency reasons. Sorry that I put my question slightly >> wrong. http://ertos.org/research/l4.verified/ states: >> >>> The next level up, the low-level design, is a detailed, executable >>> specification of the intended behaviour of the C implementation. >>> This executable specification is derived automatically from a prototype >>> of the kernel, developed in the seL4 project. The prototype was written >>> in the high-level, functional programming language Haskell >> >> So the LLD is not written in C (as I wrongly assumed above) but in some >> other executable language (Isabelle/HOL), as mentioned in section 4.7 of >> http://ertos.org/publications/papers/Klein_08.pdf) my question should >> have read: Why did you use at the LLD level not the Haskell prototype >> itself, but an automatically translated version of it? > > Yes, I should have been clearer on that. We implemented a prototype in Haskell and then translated it automatically into Isabelle/HOL. This is necessary firstly just because Haskell is not any kind of direct input format of Isabelle. Also, the translation forced us to stay within a subset of Haskell that maps nicely to HOL (Haskell as any real language has too many features). > > > >>> In this project, we see the Haskell >>> prototype as an executable specification. The performance difference is >>> enormous (we never intended the Haskell prototype to be fast, so no >>> thought whatsoever went into optimising it). >> >> Still I do not understand which was the main part of my question, namely >> why according to http://ertos.org/research/l4.verified/ your Haskell >> reference implementation is not directly in the usual verification >> chain. > > It cannot be, you can always only verify translations of programs unless you write them directly in the theorem prover (Konrad Slind et al have some nice work on compiling HOL programs directly into assembly). We make a qualitative distinction between the translation Isabelle <-> Haskell and Isabelle <-> C, because we did not have to care about the correctness of the former, but we do care about the correctness of the latter. We therefore kept Isabelle <-> C absolutely minimal and as syntactic as possible. It is really more parsing C into Isabelle than really doing any translation. Formally, both of them are translations, though. > > There is no reason that Isabelle <-> Haskell has to be a big translation step. In fact TUM and NICTA have some student projects on precisely a better, sound translation mechanism for Haskell into Isabelle. > > >> I am actually confused by what you wrote in the other email: >> >>> It turns out, though, that the Haskell <-> C proof is the smallest of the big >>> proof steps in this project. >> >> which seems to contradict http://ertos.org/research/l4.verified/ as it >> suggests that the Haskell version itself is in the verification chain. > > Sorry, I tend to shorten "the Isabelle translation of the Haskell prototype" to just "Haskell" too often. I can see that it was confusing. Did it now become clear, though? > > >> So as stated above I wonder why you use an independent executable LLD >> rather than the Prototype written in HLL (here Haskell). >> (You could also have used the Haskell prototype in between the HLD and >> LLD or in between the LLD and the hand-written C code, but this would >> add an extra (presumably superfluous) node in the verification chain.) > > No, it's actually just not possible. Isabelle does not understand Haskell (there is no theorem prover that does), it's always a translation (possibly a very small translation step). Our LLD is not independent, though. It's the product of the automatic translation. It's Haskell parsed into Isabelle if you want, although in this case there was quite a bit of transformation going on. I wrote: Maybe you have also seen on the Haskell mailing list the response of Eric Verhulst : [see above] Gerwin Klein responded: >> Eric Verhulst wrote: >>> I am not really surprised about this observation. Higher level languages >>> provide more abstraction and most programming errors are due to the >>> nitty-gritty details of the implementation. When using a language like C, >>> one should be aware that the language is basically a form of a higher level >>> assembler exposing the hardware to the program. > > I completely agree, that's why we're using it as the kernel implementation language. For most things on top of the kernel it might not be as good a choice, though. Much nicer to work in something like Haskell directly. > >> Eric Verhulst wrote: >>> In addition, it has a "dirty" syntax resulting in about 14O MISRA rules + 50 non-documented ones. > > We solve this by accepting only a true subset of C into the theorem prover. This can be made large enough to do kernel programming comfortably. It still has a lot of dirty semantic constructs that kernel programmers like to use, but that's the whole point of using it. > > David von Oheimb wrote: >> I guess you mean not only as input to the theorem prover, but also for >> the actual kernel code. This is certainly very helpful for the cleanness >> of the code and lowers the verification burden. > > Yes, absolutely. Although the kernel programmers did not necessary like all parts of the restriction, they tend to agree that it produced cleaner code. > > David von Oheimb wrote: >> I agree one cannot use HLL for very performance critical systems. >> But how about using a HLLs as form of (executable) formal model / LLD? > > Modulo a (possibly very small) translation step into the logic of the theorem prover, that's what we are advocating. > > David von Oheimb wrote: >> This, actually includes part of the answer to my above question: The LLD >> is an Isabelle/HOL model (which is isomorphic to the Haskell prototype). > > Yes! > > David von Oheimb wrote: >> In this way you avoid having the semantics of Haskell directly in the >> verification chain, but you have it indirectly (and not really formally) >> because of the automatic translation between the Haskell prototype and >> the Isabelle/HOL version of it. Therefore, the Haskell prototype is, >> strictly speaking, not an authoritative specification but the technical >> inspiration for the LLD in Isabelle/HOL. > > Exactly. If you want to build more directly on the HLL, the translation step becomes part of your trusted tool chain and you have to invest some work into making sure that it is sound. This is clearly worthwhile, though, and would be a once-for-all effort. > > David von Oheimb wrote: >> I presume the HLD is also in Isabelle/HOL. Despite your general >> bottom-up process, wouldn't it also make sense to have the HLD influence >> the LLD (and still get something useful, but hopefully more elegant)? > > That did indeed happen. We started with the LLD, but we developed the HLD concurrently (lagging slightly behind, but giving input into new iterations). Some generalisations/restrictions become more obvious when you abstract from implementation data structures. > > >> Eric Verhulst wrote: >>> But performance is often the issue and hence C is often used. Small code >>> size also means less power and less dead code, the latter also being safety >>> and security issues. In my personal view, it is hence a fallacy to say that >>> higher level languages are the solution. HLL contribute but a clean and >>> hence simple semantic model and a clean syntax are probably of higher >>> interest than a high level language that carries too much complexity and >>> overhead. > > This depends on the abstraction level of the application, I'd say. For the RTOS/microkernel level, I agree. Too much overhead is involved in using a language like Haskell directly. We used it to describe the semantics, not the actual implementation. > >> Eric Verhulst wrote: >>> Our own experience developing a network centric RTOS using formal modeling >>> also proved that the architecture is an important factor that is often >>> overlooked. While the initial set-up was to use formal modeling mainly for >>> verifying the software, it was used from the beginning for developing the >>> architecture and the functionality. The result was a big surprise. While the >>> team had more than ten years experience developing a similar RTOS in the >>> traditional way, the resulting architecture was much more straightforward >>> and clean, resulting in a code size that was 5 to 1O times smaller. The >>> architecture was also much safer (no risk of buffer overflow) and much more >>> scalable. The initial design phase took about 18 months but we had running >>> code in just 2 weeks. Later on, most issues were related to hardware issues >>> e.g. when developing drivers. > > Absolutely the same experience here. We used Haskell as the formal modelling language, because the kernel design team was more comfortable with it than with Isabelle/HOL directly, but the difference is almost syntactic only. We have had a very rapid, iterative design cycle with new features often being implemented in less than a day. > >> Eric Verhulst wrote: >>> My personal view is that for software like an RTOS, high level languages are >>> not really suitable. But for application I believe that code writing should >>> be avoided at all cost by using code generators that start from user defined >>> models, eventually complemented by formal provers (although it is early days >>> for such tools). An example is Matlab/simulink, at least in the domain of >>> e.g. algorithms. Another promising approach is to use languages (like B) >>> that allow incremental refinement with formal model checking in parallel. >>> Once such a design is complete, the risk of introducing errors even when >>> recoding into C is much lower than when writing by hand. >>> Hence, we should see these modeling tools like HLL. Nevertheless, for >>> educational purposes, such HLLs should be used a lot more often as they help >>> to learn to think in an abstract way (while most software engineers are >>> immediately influenced by their prior implementations and patterns.) Once >>> they master this, they will also write better programs in C. > > I'd even go further and say that there are HLL now that are directly suitable for application use. We tend to use Haskell, because there is a big research group at UNSW doing work on it, but I'm sure there are more. > > David von Oheimb wrote: >> Do you second his view about the benefits of a formal HLD, in his case >> TLA+/TLC according to http://www.openlicensesociety.org/drupal55/node/9 > > A formal HLD is definitely beneficial in my view. It all depends a bit on the development process you are using. Our kernel design team was used to a bottom-up process and there is no reason this cannot be supported by formal verification -- we started with the LLD and developed the HLD in parallel. I would guess that the most important aspect of all this was that we found a formal language (here Haskell) that the *kernel design team* was comfortable with. *They* need to design the kernel, they were experienced kernel designers and programmers and new to formal modelling. They had help from us formal guys, but they did most of the LLD modelling. If we (the formal guys) had designed the kernel it would be much more elegant and much more useless. > > David von Oheimb wrote: >> Unfortunately they did not verify the C code against that model. In >> order to do that, it seems that an implementation in a HLL like Haskell >> would be a good intermediate step, wouldn't it? > > I think so. If you already have the model, it doesn't need to be a programming language. It could be logic directly if the team is comfortable with using it. > > David von Oheimb wrote: >> Yes, and this would avoid bringing the semantics of the HLL into play. > > True. I wrote: Taking into account that future hardware architectures are multicore machines which are hard to program manually - Greg Kimberly writes: > The idea that C is a good representation of what's really going down at the hardware > level is obviously very compelling when you care about performance. But I wonder how > the coming world of high-number multi-core changes that? Are we entering a world where > the cost of maintaining cache coherence becomes more important than a close correspondence > to a register machine? Functional languages, with their lack of shared state, might be > a better model then. Might C ironically become considered "too far" from the hardware > to be a good choice? :-) Do you see a chance that on multicore systems, future compilers for HLLs are (on average, for large chunks of code) smarter than hand-crafted C/assembly code, such that they can be used even for performance critical code close to the system level, maybe even OS implementation? Gerwin Klein responded: > I would agree that they will be much smarter than C compilers, but at the lowest level of software like the kernel, you still need to know precisely what's going on. Too much of the safety and correctness depends on it and there smarter is not better. It's bad enough if the kernel implementers are smart (almost always means harder proofs..). HLLs also tend to rely on OS services to implement their primitives. My current feeling is still that you want to keep the kernel close to bare metal with something like C, but I would expect even more benefit from HLLs on the application and OS component level for multi core. > > All this is not to say that C is in any way a perfect language, not even for OS implementation for which it was basically developed. In my view an ideal OS implementation language would have a modern, safe type system possibly with a controlled way of "breaking" it for hardware/performance (but breaking it in a way that produces clear and simple proof obligations), no or extremely minimal required run-time, language constructs for mapping data structures to hardware layouts precisely (even C sucks in this respect), and a very clean semantics. And it shouldn't have all these "features" from the 60s like goto etc, of course.. > Greg continued writing: > And to give some idea of why you might expect a greater performance-driven interest in FL's > in the presence of very-multi-core hardware, check out the recent article in Queue about > the experience of an IBM team building a general purpose STM (soft trans memory) system: > http://queue.acm.org/detail.cfm?id=1454466 > > Basically the cost of read/write barriers are a big problem. You can see the cost > of the read barriers in particular in the detailed perf analyses. From the summary: > "Based on our results, we believe that the road ahead for STM is quite challenging. > Lowering the overhead of STM to a point where it is generally appealing is a difficult > task, and significantly better results have to be demonstrated. If we could stress > a single direction for further research, it is the elimination of dynamically > unnecessary read and write barriers-possibly the single most powerful lever toward > further reduction of STM overheads. Given the difficulty of similar problems explored > by the research community such as alias analysis, escape analysis, and so on, this > may be an uphill battle. Because the argument for TM hinges upon its simplicity and > productivity benefits, we are deeply skeptical of any proposed solutions to > performance problems that require extra work by the programmer" > > So when they call out "elimination of dynamically unnecessary read and write > barriers-possibly the single most powerful lever toward further reduction of STM > overheads" -- it leads one to think about that being precisely the sort of thing > a powerful type system and pure functional approach would seem to be ideally > suited to helping. Perhaps functional programming comes under the "extra work > by the programmer" category :-) > (Note the comment below the article specifically wondering about Haskell's STM.) Unfortunately I do not have the time to look at the above in detail; Are there are others who might do or already have an opinion/insight in this issue? Greg continued writing: > So if folks can find a way to make writing correct programs more verifiable in > FL's the performance issue might very well be a non-issue in a few years.... Wouldn't this be great! Greg also wrote: > Still, I clearly need to look at current practice in code generators (from models). > Though I imagine they still involve even larger space/time compromises than using > HLL's relative to coding in C. So I'm a bit surprised at Mr. Verhulst's enthusiasm > for them as compared the HLL's. It might be a case of the grass being greener on the > other side of the fence, I think. It seems to me that Mr. Verhulst would also be fine with HLLs as a formal model, and that for very performance critical code he is just dissatisfied with the efficiency of compilers and code generators, and therefore prefers (any) formal model that this manually translated to C for efficiency, right? Gerwin Klein responded: > Sounds like it. I might add, that for us it's not just about the efficiency (although that is a big factor), but also about knowing precisely how things map to the hardware. Gerwin Klein wrote: > All this is not to say that C is in any way a perfect language, not even > for OS implementation for which it was basically developed. In my view > an ideal OS implementation language would have a modern, safe type > system possibly with a controlled way of "breaking" it for > hardware/performance (but breaking it in a way that produces clear and > simple proof obligations), no or extremely minimal required run-time, > language constructs for mapping data structures to hardware layouts > precisely (even C sucks in this respect), and a very clean semantics. > And it shouldn't have all these "features" from the 60s like goto etc, > of course.. This is obviously why you, and others, use some strict subset of C. Just a pity that neither of them has become a widely accepted coding standard, or even better, evolved into a new, clean version of C. Do you happen to know Scala, and what you think about it? http://www.scala-lang.org/node/25 Gerwin Klein responded: > I haven't used it extensively, but I like it as a language. Makarius is using it for Isabelle quite a bit these days, he might have more insight. *********************************************************************** Grit Denker wrote: > David, > One thing that comes to mind is the work from Mark-Oliver Stehr and > Carolyn Talcott. > In particular, I think they formalized in Maude a secure group protocol > and did some verification on it. > > See http://formal.cs.uiuc.edu/stehr/cliques_eng.html > If you need more info, contact Mark-Oliver Stehr at stehr@csl.sri.com > > John Rushby should have a lot more stories about successful use of > FM.Maybe there is something on http://fm.csl.sri.com/ > > grit *********************************************************************** Lars-Henrik Eriksson wrote: > Hi, > > I carried out a formal verification of a Prolog program 10 years ago > while I was working at Industrilogik L4i AB, a Swedish formal methods > consultancy which was acquired by Prover Technology (www.prover.com) > some years ago. The program was a front end to a SAT solver and > converted a formula in a first order language with finite domains to a > propositional logic formula. The conversion was slightly tricky since it > included several simplification steps. The program was just over 500 > lines in size (excluding comments and blank lines). > > The verified program was going to be used as part of a commercial formal > verification tool and the client (now Bombardier Transportation Rail > Control Solutions) wanted some assurance that the tool worked correctly. > > I used Robert St?rk's Logic Program Theorem Prover > (http://www.inf.ethz.ch/personal/staerk/lptp.html). As this was a > commercial project, there was no report written on the verification work > as such. As far as I remember, St?rk's LPTP system worked quite well. > > Best regards, > > Lars-Henrik Eriksson, PhD, Senior Lecturer > Computing Science, Dept. of Information Technology, Uppsala University, Sweden *********************************************************************** Amine Chaieb wrote: > Hi, > > Maybe not that "big" components, but we verified formally (in > Isabelle/HOL) some decision procedure implementations (mainly quantifier > elimination for linear real, integer arithmetic and their combination). > Using Isabelle's push button Technology you transform the formally > Isabelle/HOL implementation in to SML, Ocaml or Haskell. > > Here are some pointers: > > http://www.cl.cam.ac.uk/~ac638/pubs/pdf/mir.pdf > http://www.cl.cam.ac.uk/~ac638/pubs/pdf/frpar.pdf > http://www.cl.cam.ac.uk/~ac638/pubs/pdf/linear.pdf > > Best wishes, > Amine. *********************************************************************** Niklas Holsti wrote: > Hello David, > > I don't know if by "such a language" you mean specifically > functional/logic languages, but in case not: You probably know about the > Tokeener software, > http://www.adacore.com/home/gnatpro/tokeneer/ > which is implemented in SPARK Ada. Not a functional language, but one in > which data flow is controlled and verified, using the SPARK Examiner > toolset. > > Regards, > > Niklas Holsti > Tidorum Ltd *********************************************************************** David von Oheimb wrote: > Dear all, > > at Siemens Corporate Technology we are currently doing a study with > Boeing on how to enhance assurance of open-source security-critical > software components like OpenSSL. Methods considered range from standard > static analysis tools to formal verification. > > One observation is that the higher the programming language used is, > the less likely programming mistakes are, and the easier a formal model > can be obtained and the more likely it is to be faithful and verifiable. > In this sense, implementations e.g. in a functional/logic programming > language would be ideal. > > Are you aware of any (security critical or other) software component > that has been implemented in such a high-level language and has been > formally verified? Any quick pointers etc. are appreciated. > > Thanks, > David v.Oheimb > > +------------------------------------------------------------------<><-+ > | Dr. David von Oheimb Senior Research Scientist | > | Siemens AG, CT IC 3 Phone : +49 89 636 41173 | > | Otto-Hahn-Ring 6 Fax : +49 89 636 48000 | > | 81730 M?nchen Mobile: +49 171 8677 885 | > | Germany E-Mail: David.von.Oheimb@siemens.com | > | http://scd.siemens.de/db4/lookUp?tcgid=Z000ECRO http://ddvo.net/ | > +----------------------------------------------------------------------+ > > _______________________________________________ fortia mailing list fortia@fmeurope.org http://fmeurope.hosting.west.nl/mailman/listinfo/fortia From dons at galois.com Sat Mar 21 12:58:48 2009 From: dons at galois.com (Don Stewart) Date: Sat Mar 21 12:47:33 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> References: <20090317023944.GN8842@sliver.repetae.net> <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> Message-ID: <20090321165848.GB20212@whirlpool.galois.com> sylvain.nahas: > Hi, > > This compiler is very promising, for the least. > > Here is a small dummy Haskell program. > countdown :: Int -> IO () > countdown 0 = putStrLn "finished" > countdown x = do > putStrLn (show x) > countdown (x-1) > main = countdown 10000000 > > and the C program that comes to closest. > #include > int main(void) > { > int i; > for(i=0; i<10000000; i++) > { > printf("%d\n",i); > } > printf("finished\n"); > return 0; > } > > GHC is 6.10.1, gcc is 4.3.2, jhc is 0.6.0 > arch is i386/Linux(Ubuntu) > > $ ghc hello.hs -o hello1 > $ jhc hello.hs -o hello2 > $ gcc hello.c -o hello3 Oh boy. Compile with optimizations on please! ghc -O2 et al. From dons at galois.com Sat Mar 21 13:00:33 2009 From: dons at galois.com (Don Stewart) Date: Sat Mar 21 12:49:12 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <20090317023944.GN8842@sliver.repetae.net> References: <20090317023944.GN8842@sliver.repetae.net> Message-ID: <20090321170033.GC20212@whirlpool.galois.com> john: > Hi, I am pleased to announce jhc 0.6.0, It has been a long time since an > official release, so there have been a lot of changes. Jhc is an > optimizing haskell compiler that focuses on creating fast and portable > code. Jhc is still mainly of interest to jhc hackers and developers than > the general haskell public, but it is starting to see use in embedded > development with haskell so I decided to make more public announcements > of major releases in the future. > Hey John, I get the following build error: /usr/bin/ghc -fbang-patterns -O -ignore-package lang -W -fno-warn-unused-matches -fwarn-type-defaults -i -i./drift_processed -i./. -i. -odir . -hidir . -package mtl -package unix -ignore-package lang -package utf8-string -package binary -package zlib -fallow-undecidable-instances -fglasgow-exts -fallow-overlapping-instances --make Main.hs StringTable/StringTable_cbits.o cbits/md5sum.o -o jhc on the commandline: Warning: -fbang-patterns is deprecated: use -XBangPatterns or pragma {-# LANGUAGE BangPatterns#-} instead on the commandline: Warning: -fallow-undecidable-instances is deprecated: use -XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances#-} instead on the commandline: Warning: -fallow-overlapping-instances is deprecated: use -XOverlappingInstances or pragma {-# LANGUAGE OverlappingInstances#-} instead Util/Gen.hs:6:7: Could not find module `Control.Monad.Identity': it was found in multiple packages: transformers-0.1.1.0 mtl-1.1.0.2 make[1]: *** [jhc] Error 1 I *think* you have to -hide-all-packages then enable the ones you want one-by-one (check whatever commandline cabal emits here). Cheers, Don From martijn at van.steenbergen.nl Sat Mar 21 13:18:00 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Sat Mar 21 13:06:07 2009 Subject: [Haskell] Re: [Haskell-cafe] [ANN] ansi-terminal, ansi-wl-pprint - ANSI terminal support for Haskell In-Reply-To: <9d4d38820903210930x14c6ef9ai7b5681c2f74ee15b@mail.gmail.com> References: <9d4d38820903210930x14c6ef9ai7b5681c2f74ee15b@mail.gmail.com> Message-ID: <49C52148.7070301@van.steenbergen.nl> Max Bolingbroke wrote: > These two packages allow Haskell programs to produce much richer > console output by allowing colorisation, emboldening and so on. This will be a big help in my MUD driver. Thanks! :-) Martijn. From sylvain.nahas at googlemail.com Sat Mar 21 18:00:50 2009 From: sylvain.nahas at googlemail.com (sylvain) Date: Sat Mar 21 17:48:36 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <20090321165848.GB20212@whirlpool.galois.com> References: <20090317023944.GN8842@sliver.repetae.net> <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> <20090321165848.GB20212@whirlpool.galois.com> Message-ID: <1237672850.7638.13.camel@dell.linuxdev.us.dell.com> Le samedi 21 mars 2009 ? 09:58 -0700, Don Stewart a ?crit : > Oh boy. Compile with optimizations on please! ghc -O2 et al. Hi. I had done that, actually, before even my first post, and knew that it changes little to the picture, at least on my system. Please check the other post, where I publish the results with optimization turned on. http://www.haskell.org/pipermail/jhc/2009-March/000311.html I have also tested with another program, from the "Great Computer Language Shootout". http://www.haskell.org/pipermail/jhc/2009-March/000313.html Sylvain Nahas From john at repetae.net Sun Mar 22 22:12:37 2009 From: john at repetae.net (John Meacham) Date: Sun Mar 22 22:00:17 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <20090321170033.GC20212@whirlpool.galois.com> References: <20090317023944.GN8842@sliver.repetae.net> <20090321170033.GC20212@whirlpool.galois.com> Message-ID: <20090323021237.GH11188@sliver.repetae.net> On Sat, Mar 21, 2009 at 10:00:33AM -0700, Don Stewart wrote: > john: > > Hi, I am pleased to announce jhc 0.6.0, It has been a long time since an > > official release, so there have been a lot of changes. Jhc is an > > optimizing haskell compiler that focuses on creating fast and portable > > code. Jhc is still mainly of interest to jhc hackers and developers than > > the general haskell public, but it is starting to see use in embedded > > development with haskell so I decided to make more public announcements > > of major releases in the future. > > > > > Hey John, > > I get the following build error: > > /usr/bin/ghc -fbang-patterns -O -ignore-package lang -W -fno-warn-unused-matches -fwarn-type-defaults -i -i./drift_processed -i./. -i. -odir . -hidir . -package mtl -package unix -ignore-package lang -package utf8-string -package binary -package zlib -fallow-undecidable-instances -fglasgow-exts -fallow-overlapping-instances --make Main.hs StringTable/StringTable_cbits.o cbits/md5sum.o -o jhc > > on the commandline: > Warning: -fbang-patterns is deprecated: use -XBangPatterns or pragma {-# LANGUAGE BangPatterns#-} instead > > on the commandline: > Warning: -fallow-undecidable-instances is deprecated: use -XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances#-} instead > > on the commandline: > Warning: -fallow-overlapping-instances is deprecated: use -XOverlappingInstances or pragma {-# LANGUAGE OverlappingInstances#-} instead > > Util/Gen.hs:6:7: > Could not find module `Control.Monad.Identity': > it was found in multiple packages: transformers-0.1.1.0 mtl-1.1.0.2 > make[1]: *** [jhc] Error 1 > > > I *think* you have to -hide-all-packages then enable the ones you want one-by-one (check whatever > commandline cabal emits here). Hmm... what version of ghc are you using? I tested against ghc 6.8 since that is all I have available on my machines so it is possible the bugs are because you are using ghc 6.10. If the -hide-all-packages trick works for 6.8 too then I will do that always. I dropped 6.6 compatability at some point, but want to keep 6.8 in addition to 6.10 since that is among other things what amazon ec2 instances come with (since they are based on fedora core 8). Man. those high CPU ec2 instances are great for plowing through regression tests. :) John -- John Meacham - ?repetae.net?john? From john at repetae.net Sun Mar 22 22:25:54 2009 From: john at repetae.net (John Meacham) Date: Sun Mar 22 22:13:34 2009 Subject: [jhc] Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: References: <20090317023944.GN8842@sliver.repetae.net> Message-ID: <20090323022554.GI11188@sliver.repetae.net> On Thu, Mar 19, 2009 at 03:22:33PM +0100, Alberto G. Corona wrote: > The last version still uses a region inference algoritm instead of a garbage > collector?. It turns out the choice of garbage collector is fairly independent of the rest of the compiler, so there is a flag to decide on what garbage collector to use (or none). Right now, however, there isn't really a universally good choice, the boehm gc will work, but it is quite slow. I am working on a middle of the road solution between full static analysis and garbage collection based on the mercury garbage collector for compilation to C, but of course, when compiling to something like llvm or C--, a different garbage collector might be in order. So, It is likely jhc will have multiple choices when it comes to garbage collection for a while until an obviously correct answer emerges. In the meantime, improving the static analysis (such as full region inference will do) helps all back ends so I will likely spend some time focusing on that. John -- John Meacham - ?repetae.net?john? From ketil at malde.org Mon Mar 23 03:40:02 2009 From: ketil at malde.org (Ketil Malde) Date: Mon Mar 23 03:26:51 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <1237672850.7638.13.camel@dell.linuxdev.us.dell.com> (sylvain's message of "Sat\, 21 Mar 2009 23\:00\:50 +0100") References: <20090317023944.GN8842@sliver.repetae.net> <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> <20090321165848.GB20212@whirlpool.galois.com> <1237672850.7638.13.camel@dell.linuxdev.us.dell.com> Message-ID: <874oxkpu0d.fsf@malde.org> sylvain writes: > Le samedi 21 mars 2009 ? 09:58 -0700, Don Stewart a ?crit : >> Oh boy. Compile with optimizations on please! ghc -O2 et al. > I had done that, actually, before even my first post, and knew that it > changes little to the picture, at least on my system. I think Bulat was right on the money here: you're essentially testing the efficiency of writing integers. Presumably, JHC is better than GHC at specializing/inlining this library function. -k -- If I haven't seen further, it is by standing in the footprints of giants From john at repetae.net Mon Mar 23 04:09:15 2009 From: john at repetae.net (John Meacham) Date: Mon Mar 23 03:56:54 2009 Subject: [jhc] Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <874oxkpu0d.fsf@malde.org> References: <20090317023944.GN8842@sliver.repetae.net> <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> <20090321165848.GB20212@whirlpool.galois.com> <1237672850.7638.13.camel@dell.linuxdev.us.dell.com> <874oxkpu0d.fsf@malde.org> Message-ID: <20090323080915.GJ11188@sliver.repetae.net> On Mon, Mar 23, 2009 at 08:40:02AM +0100, Ketil Malde wrote: > > I had done that, actually, before even my first post, and knew that it > > changes little to the picture, at least on my system. > > I think Bulat was right on the money here: you're essentially testing > the efficiency of writing integers. Presumably, JHC is better than > GHC at specializing/inlining this library function. Indeed, but isn't being better at specializing/inlining exactly what an optimizing compiler should do. :) In any case, these results are not atypical, generally, if jhc can compile something, it ends up being 2-3x faster than ghc. After all, C-comparable (or even superior) speed is the main goal of jhc development. And if anything, I am more convinced than when I started that the goal is achievable. With jhc today, C comparable performance from numerical code is not difficult to achieve with some attention to strictness annotations. John -- John Meacham - ?repetae.net?john? From sescobar at dsic.upv.es Mon Mar 23 06:04:47 2009 From: sescobar at dsic.upv.es (Santiago Escobar) Date: Mon Mar 23 05:52:27 2009 Subject: [Haskell] Cfp: WFLP09 - 18th Int'l Workshop on Functional and (Constraint) Logic Programming References: Message-ID: <6E741A05-9D2D-4762-A23A-03ABA4ED8A56@dsic.upv.es> ******************************************************************* Call For Papers WFLP 2009 18th International Workshop on Functional and (Constraint) Logic Programming Brasilia, Brazil, June, 28, 2009 http://www.dsic.upv.es/workshops/wflp09/ ********* part of the Federated Conference on Rewriting, Deduction, and Programming RDP'09 http://rdp09.cic.unb.br/index.html ******************************************************************* IMPORTANT DATES Abstract Submission April 20, 2009 Full Paper Submission April 26, 2009 Acceptance Notification May 25, 2009 Preliminary Proceedings June 8, 2009 Workshop June 28, 2009 SCOPE The Workshop on Functional and (Constraint) Logic Programming aims at bringing together researchers interested in functional programming, (constraint) logic programming, as well as the integration of the two paradigms. It promotes the cross-fertilizing exchange of ideas and experiences among researchers and students from the different communities interested in the foundations, applications, and combinations of high-level, declarative programming languages and related areas. The previous WFLP editions are: WFLP 2008 (Siena, Italy), WFLP 2007 (Paris, France), WFLP 2006 (Madrid, Spain), WCFLP 2005 (Tallinn, Estonia), WFLP 2004 (Aachen, Germany), WFLP 2003 (Valencia, Spain), WFLP 2002 (Grado, Italy), WFLP 2001 (Kiel, Germany), WFLP 2000 (Benicassim, Spain), WFLP'99 (Grenoble, France), WFLP'98 (Bad Honnef, Germany), WFLP'97 (Schwarzenberg, Germany), WFLP'96 (Marburg, Germany), WFLP'95 (Schwarzenberg, Germany), WFLP'94 (Schwarzenberg, Germany), WFLP'93 (Rattenberg, Germany), and WFLP'92 (Karlsruhe, Germany). LOCATION WFLP'09 will be held in June 28, 2009 at Brasilia, Brazil, as part of the Federated Conference on Rewriting, Deduction, and Programming (RDP'09). WFLP'09 solicits papers in all areas of functional and (constraint) logic programming, including but not limited to: * Foundations: formal semantics, rewriting and narrowing, constraint solving, dynamics, type theory * Language Design: modules and type systems, multi-paradigm languages, concurrency and distribution, objects * Implementation: abstract machines, parallelism, compile-time and run-time optimizations, interfacing with external languages * Transformation and Analysis: abstract interpretation, specialization, partial evaluation, program transformation, meta-programming * Software Engineering: design patterns, specification, verification and validation, debugging, test generation * Integration of Paradigms: integration of declarative programming with other paradigms such as imperative, object-oriented, concurrent, and real-time programming * Applications: security, declarative programming in education and industry, domain-specific languages, visual/graphical user interfaces, embedded systems, WWW applications, knowledge representation and machine learning, deductive databases, advanced programming environments and tools SUBMISSIONS and PROCEEDINGS Authors are invited to submit papers of at most 15 pages (pdf or postscript formats) presenting original, not previously published works. Submission categories include regular research papers, short papers (not more than 8 pages) describing on-going work, and system descriptions. Submissions must be formatted in the Lecture Notes in Computer Science style (excluding well-marked appendices not intended for publication). Papers should be submitted electronically via the web-based submission site http://www.easychair.org/conferences/?conf=wflp2009 Preliminary proceedings will be available at the workshop. Selected authors will be invited to submit a full version of their papers after the workshop. Contributions accepted for the post-workshop proceedings will be published in Lecture Notes in Computer Science. INVITED SPEAKERS Claude Kirchner INRIA Bordeaux - Sud-Ouest, France Roberto Ierusalimschy Departamento de Informatica, PUC-Rio, Brazil PROGRAM CHAIR Santiago Escobar Universidad Politecnica de Valencia, Spain PROGRAM COMMITTEE Maria Alpuente Universidad Politecnica de Valencia, Spain Sergio Antoy Portland State University, USA Christiano Braga Universidade Federal Fluminense, Brazil Rafael Caballero Universidad Complutense de Madrid, Spain David Deharbe Universidade Federal do Rio Grande do Norte, Brazil Rachid Echahed CNRS,laboratoire LIG, France Moreno Falaschi Universita di Siena, Italy Michael Hanus Christian-Albrechts-Universitaet zu Kiel, Germany Frank Huch Christian-Albrechts-Universitaet zu Kiel, Germany Tetsuo Ida University of Tsukuba, Japan Wolfgang Lux Westfalische Wilhelms-Universitat Munster, Germany Mircea Marin University of Tsukuba, Japan Camilo Rueda Universidad Javeriana-Cali, Colombia Jaime Sanchez-Hernandez Universidad Complutense de Madrid, Spain Anderson Santana de Oliveira Universidade Federal do Rio Grande do Norte, Brazil From pepe.haskell at gmail.com Mon Mar 23 07:07:32 2009 From: pepe.haskell at gmail.com (Pepe Gallardo) Date: Mon Mar 23 06:55:28 2009 Subject: [Haskell] ANNOUNCE: WinGhci, a GUI for GHCI on Windows Message-ID: <84f82ca10903230407o23202e86hfca41af7000785b7@mail.gmail.com> Hi, I am pleased to announce the first release of WinGhci. WinGhci is a simple GUI for GHCI on Windows. It is closely based on WinHugs, and provides similar functionality. WinGhci project web page: http://code.google.com/p/winghci/ Binaries: http://winghci.googlecode.com/files/WinGhci-1.0-bin.zip Sources: http://winghci.googlecode.com/files/WinGhci-1.0-src.zip Acknowledgements Much of the code in WinGhci was taken from the Winhugs project. Many thanks to Neil Mitchell for giving us permission to use his code. Pepe Gallardo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090323/1e5442d4/attachment.htm From dons at galois.com Mon Mar 23 12:26:29 2009 From: dons at galois.com (Don Stewart) Date: Mon Mar 23 12:15:26 2009 Subject: [Haskell] Hackage download and popularity statistics Message-ID: <20090323162629.GG371@whirlpool.galois.com> For the first time, we've got download and popularity statistics from Hackage: http://www.galois.com/blog/2009/03/23/one-million-haskell-downloads/ Find out if your package made the top 100, and when we reach our 1 millionth hackage download! -- Don From lists at qseep.net Mon Mar 23 12:57:57 2009 From: lists at qseep.net (Lyle Kopnicky) Date: Mon Mar 23 12:45:35 2009 Subject: [jhc] Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <20090323080915.GJ11188@sliver.repetae.net> References: <20090317023944.GN8842@sliver.repetae.net> <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> <20090321165848.GB20212@whirlpool.galois.com> <1237672850.7638.13.camel@dell.linuxdev.us.dell.com> <874oxkpu0d.fsf@malde.org> <20090323080915.GJ11188@sliver.repetae.net> Message-ID: <670e468e0903230957y25a7936ci87b4605d30a656b9@mail.gmail.com> Those are impressive results. Typically on programming language benchmarks, the speed of ghc-generated code fares well against C, sometimes outperforming it, at best being 20x faster, at worst being 3x slower. Since it already seems "fast enough", I'm astonished that jhc could make it even faster. http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=ghc&lang2=gcc&box=1 Where ghc-generated code fares poorly against other languages is memory usage. Has there been an effort in jhc to reduce the memory footprint of generated code? How does it fare against ghc in this area? Thanks, Lyle On Mon, Mar 23, 2009 at 1:09 AM, John Meacham wrote: > On Mon, Mar 23, 2009 at 08:40:02AM +0100, Ketil Malde wrote: > > > I had done that, actually, before even my first post, and knew that it > > > changes little to the picture, at least on my system. > > > > I think Bulat was right on the money here: you're essentially testing > > the efficiency of writing integers. Presumably, JHC is better than > > GHC at specializing/inlining this library function. > > Indeed, but isn't being better at specializing/inlining exactly what an > optimizing compiler should do. :) > > In any case, these results are not atypical, generally, if jhc can > compile something, it ends up being 2-3x faster than ghc. After all, > C-comparable (or even superior) speed is the main goal of jhc > development. And if anything, I am more convinced than when I started > that the goal is achievable. With jhc today, C comparable performance > from numerical code is not difficult to achieve with some attention to > strictness annotations. > > John > > -- > John Meacham - ?repetae.net?john? > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090323/cde887d0/attachment.htm From taralx at gmail.com Mon Mar 23 14:11:45 2009 From: taralx at gmail.com (Taral) Date: Mon Mar 23 13:59:23 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <20090321170033.GC20212@whirlpool.galois.com> References: <20090317023944.GN8842@sliver.repetae.net> <20090321170033.GC20212@whirlpool.galois.com> Message-ID: On Sat, Mar 21, 2009 at 10:00 AM, Don Stewart wrote: > Util/Gen.hs:6:7: > ? ?Could not find module `Control.Monad.Identity': > ? ? ?it was found in multiple packages: transformers-0.1.1.0 mtl-1.1.0.2 > make[1]: *** [jhc] Error 1 ghc-pkg hide transformers-0.1.1.0 -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown From dons at galois.com Tue Mar 24 11:20:22 2009 From: dons at galois.com (Don Stewart) Date: Tue Mar 24 11:08:56 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <000001c9ac7a$bcac5d10$36051730$@vers@telenet.be> References: <20090317023944.GN8842@sliver.repetae.net> <20090321170033.GC20212@whirlpool.galois.com> <000001c9ac7a$bcac5d10$36051730$@vers@telenet.be> Message-ID: <20090324152022.GJ3971@whirlpool.galois.com> peter.vers: > > On Sat, Mar 21, 2009 at 10:00 AM, Don Stewart wrote: > > ghc-pkg hide transformers-0.1.1.0 > > But that is an global change no? Can this be configured in the cabal file? > > -hide-package in a Makefile. Cabal handles this automatically for you, by hiding everything by default, and then enabling only those things explicitly listed. From sylvain.nahas at googlemail.com Tue Mar 24 19:12:03 2009 From: sylvain.nahas at googlemail.com (sylvain) Date: Tue Mar 24 18:59:47 2009 Subject: [jhc] Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler In-Reply-To: <670e468e0903230957y25a7936ci87b4605d30a656b9@mail.gmail.com> References: <20090317023944.GN8842@sliver.repetae.net> <1237418166.8888.41.camel@dell.linuxdev.us.dell.com> <20090321165848.GB20212@whirlpool.galois.com> <1237672850.7638.13.camel@dell.linuxdev.us.dell.com> <874oxkpu0d.fsf@malde.org> <20090323080915.GJ11188@sliver.repetae.net> <670e468e0903230957y25a7936ci87b4605d30a656b9@mail.gmail.com> Message-ID: <1237936323.2814.9.camel@dell.linuxdev.us.dell.com> Hi, your post gave me the idea to profile the memory usage of the generated binary with valgrind. > Has there been an effort in jhc to reduce the memory footprint of > generated code? In this release of jhc, the problem is handled in a quite radical way. It seems that no free() is ever emitted, the allocated heap memory is not released. Well, this classifies like a bug, I guess. On the bright side, when I removed all memory deallocation from the C version, supposing (naively maybe) that it would radicaly reduce the difference in performance, jhc's still ran twice faster. Sylvain Nahas From mgvaldesgraterol at gmail.com Wed Mar 25 02:48:54 2009 From: mgvaldesgraterol at gmail.com (Maria Gabriela Valdes) Date: Wed Mar 25 02:36:26 2009 Subject: [Haskell] Google Summer of Code Help and suggestions Message-ID: <15a2b5440903242348o51a873baw9806407cb8136fe4@mail.gmail.com> Hi, my name is Maria Gabriela Valdes, i'm a new member of the mailing list, but i'm not new using haskell. Currently i'm studying computer science in Venezuela. I'm writing because i want to know more about de haskell community. I'm looking foward to knowing a lot of knew people and learing a lot more about haskell. -- -- Maria Gabriela Valdes G. Linux Registered User #485743 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090326/a938e45d/attachment.htm From byorgey at seas.upenn.edu Wed Mar 25 10:20:56 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Wed Mar 25 10:08:28 2009 Subject: [Haskell] Google Summer of Code Help and suggestions In-Reply-To: <15a2b5440903242348o51a873baw9806407cb8136fe4@mail.gmail.com> References: <15a2b5440903242348o51a873baw9806407cb8136fe4@mail.gmail.com> Message-ID: <20090325142056.GB19880@seas.upenn.edu> On Thu, Mar 26, 2009 at 02:18:54AM +1930, Maria Gabriela Valdes wrote: > Hi, my name is Maria Gabriela Valdes, i'm a new member of the mailing list, > but i'm not new using haskell. Currently i'm studying computer science in > Venezuela. > > I'm writing because i want to know more about de haskell community. I'm > looking foward to knowing a lot of knew people and learing a lot more about > haskell. Hi Maria, welcome! A good place to learn more about the Haskell community is on the wiki, http://haskell.org/. You should also feel free to come by the #haskell IRC channel on chat.freenode.net, it's a friendly place with lots of discussion. If you're looking for ideas for GSOC, you should check out the "Project ideas" link on the Haskell GSOC page: http://hackage.haskell.org/trac/summer-of-code/wiki/Soc2009 . Good luck! -Brent From urban at math.lmu.de Wed Mar 25 14:31:37 2009 From: urban at math.lmu.de (urban@math.lmu.de) Date: Wed Mar 25 14:19:10 2009 Subject: [Haskell] WMM'09 call for papers Message-ID: <20090325193137.ll7j3wnascw00ok8@webmail.mathematik.uni-muenchen.de> Call for Papers 4rd Informal ACM SIGPLAN Workshop on Mechanizing Metatheory Edinburgh, Scotland Co-located with ICFP'09. http://www.cis.upenn.edu/~sweirich/wmm/ Important Dates * Submission deadline: 19 June 2009 * Author Notification: 24 July 2009 * Workshop: 4 September 2009 Workshop Description Researchers in programming languages have long felt the need for tools to help formalize and check their work. With advances in language technology demanding deep understanding of ever larger and more complex languages, this need has become urgent. There are a number of automated proof assistants being developed within the theorem proving community that seem ready or nearly ready to be applied in this domain-yet, despite numerous individual efforts in this direction, the use of proof assistants in programming language research is still not commonplace: the available tools are confusingly diverse, difficult to learn, inadequately documented, and lacking in specific library facilities required for work in programming languages. The goal of this workshop is to bring together researchers who have experience using automated proof assistants for programming language metatheory, and those who are interested in using tool support for formalizing their work. One starting point for discussion will be the obstacles that hinder mechanization (whether they be pragmatic or technical), and what users and developers can do to overcome them. Format The workshop will consist of presentations by the participants, selected from submitted abstracts. It will focus on providing a fruitful environment for interaction and presentation of ongoing work. Participants are invited to submit working notes, source files, and abstracts for distribution to the attendees, but as the workshop has no formal proceedings, contributions may still be submitted for publication elsewhere. (See the SIGPLAN republication policy for more details.) Scope The scope of the workshop includes, but is not limited to: * Tool demonstrations: proof assistants, logical frameworks, visualizers, etc. * Libraries for programming language metatheory. * Formalization techniques, especially with respect to binding issues. * Analysis and comparison of solutions to the POPLmark challenge. * Examples of formalized programming language metatheory. * Proposals for new challenge problems that benchmark programming language work. Submission Guidelines Email submissions to urbanc AT in.tum.de. Submissions should be no longer than two pages in PDF and printable on A4 sized paper. Persons for whom this poses a hardship should contact the program chair. Conference Organization Program Committee * Nick Benton, Microsoft Research Cambridge * Olivier Danvy, University of Aarhus * Daniel Licata, Carnegie Mellon University * Francois Pottier, INRIA Paris-Rocquencourt * Christian Urban, TU Munich (chair) Workshop Organizers * Karl Crary, Carnegie Mellon University * Michael Norrish, National ICT Australia * Stephanie Weirich, University of Pennsylvania Previous Workshops * Victoria, 2008 * Freiburg, 2007 * Portland, 2006 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From hjgtuyl at chello.nl Thu Mar 26 15:41:57 2009 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Thu Mar 26 15:29:55 2009 Subject: [Haskell] ANNOUNCE: wxAsteroids 1.0 Message-ID: Your space ship enters an asteroid belt, try to avoid collisions! wxAsteroids is a game demonstrating the wxHaskell GUI. More about this at: http://www.haskell.org/haskellwiki/wxAsteroids -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From p.k.f.holzenspies at utwente.nl Fri Mar 27 04:47:58 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Fri Mar 27 04:32:22 2009 Subject: [Haskell] jhc dependencies for ghc-6.10.1 Message-ID: <1238143678.22719.12.camel@ewi1043> Dear John, et al. I will be trying jhc out, because it sounds like a good idea for some of my number-crunching apps. I just wanted to tell you how my build with ghc-6.10.1 (out-of-the-box) went, although it's not completely fair, because I may have some things from hackage installed already. Anyhow, I followed your requirement list (binary,zlib,utf8-string) and ran into the following missing dependencies: readline fgl These were removed from ghc and extralibs, resp. You may want to list these on your installation page for 6.10 builds. Also, people may like to be pointed to this ticket (I ran into this): http://hackage.haskell.org/trac/ghc/ticket/2897 Two more things that struck me: - After the installation of jhc, I just had to try it: took a clean directory fresh from the tarball, did ./configure --with-hc=jhc && make. Unfortunately: /home/holzensp/usr/bin/jhc -I./StringTable -I./cbits -I./cbits -optc-std=c99 -optc-O2 -optc-Wall StringTable/StringTable_cbits.c -c -o StringTable/StringTable_cbits.o Error: Module not found: StringTable/StringTable_cbits.c make[1]: *** [StringTable/StringTable_cbits.o] Error 1 - After the initial installation a directory appeared in my $HOME/usr/share, called jhc-0.5. It seems not all version numbers were bumped ;) Regards, Philip From hjgtuyl at chello.nl Fri Mar 27 10:34:06 2009 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Fri Mar 27 10:22:04 2009 Subject: [Haskell] Re: [Haskell-cafe] ANNOUNCE: wxAsteroids 1.0 In-Reply-To: References: Message-ID: On Thu, 26 Mar 2009 20:41:57 +0100, Henk-Jan van Tuyl wrote: > > Your space ship enters an asteroid belt, try to avoid > collisions! > > wxAsteroids is a game demonstrating the wxHaskell GUI. > > More about this at: > http://www.haskell.org/haskellwiki/wxAsteroids Maybe I should add more informationn to this: The main purpose of this game is to learn how to use wxHaskell; it also shows, in the main function, how a cabalized program can find its data files. I don't want to take the credit for this program; I took the source code and images from the paper: wxHaskell - A Portable and Concise GUI Library for Haskell [1] by Daan Leijen. If you want to learn how to use wxHaskell, I can advise you to read this paper. Daan gave me permission to publish the code with a BSD license. [1] http://legacy.cs.uu.nl/daan/download/papers/wxhaskell.pdf -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From fmics2009 at dsic.upv.es Fri Mar 27 10:44:47 2009 From: fmics2009 at dsic.upv.es (FMICS 2009 workshop chair) Date: Fri Mar 27 10:36:38 2009 Subject: [Haskell] [FMICS 2009] Fourth Call for Papers Message-ID: <49CCE65F.2080607@dsic.upv.es> FMICS 2009 - 4TH CALL FOR PAPERS Please visit: http://users.dsic.upv.es/workshops/fmics2009 ************************************************************ * 14th International Workshop on * * Formal Methods for Industrial Critical Systems * * FMICS 2009 * * * * November 2-3, 2009 * * Eindhoven, The Netherlands * ************************************************************ * ** NEWS ** * * * * >> Invited speakers confirmed * * Dino Distefano Queen Mary, Univ. London, UK * * Diego Latella ISTI-CNR, Italy * * Thierry Lecomte ClearSy, France * * Ken McMillan Cadence, USA * * * ************************************************************ * * * LNCS proceedings * * Springer has confirmed that the proceedings * * will be published in their Lecture Notes in * * Computer Science series. * * * * Price for best paper -- awarded by EASST * * * ************************************************************ IMPORTANT DATES --------------- Deadline for abstracts: 1st April Deadline for papers: 7 April Accept/Reject notification: 15 June Camera-ready version: 15 July Workshop: 2-3 November SCOPE OF THE WORKSHOP --------------------- The aim of the ERCIM FMICS workshop series is to provide a forum for researchers who are interested in the development and application of formal methods in industry. In particular, these workshops bring together scientists and engineers that are active in the area of formal methods and interested in exchanging their experiences in the industrial usage of these methods. These workshops also strive to promote research and development for the improvement of formal methods and tools for industrial applications. Topics include, but are not restricted to: - Design, specification, code generation and testing based on formal methods. - Methods, techniques and tools to support automated analysis, certification, debugging, learning, optimization and transformation of complex, distributed, real-time systems and embedded systems. - Verification and validation methods that address shortcomings of existing methods with respect to their industrial applicability (e.g., scalability and usability issues). - Tools for the development of formal design descriptions. - Case studies and experience reports on industrial applications of formal methods, focusing on lessons learned or identification of new research directions. - Impact of the adoption of formal methods on the development process and associated costs. - Application of formal methods in standardization and industrial forums. INVITED SPEAKERS ---------------- Dino Distefano Queen Mary, Univ. London, UK Diego Latella ISTI-CNR, Italy Thierry Lecomte ClearSy, France Ken McMillan Cadence, USA CO-CHAIRS --------- Maria Alpuente Tech. University Valencia, Spain Byron Cook Microsoft Research, UK PROGRAM COMMITTEE ------------------- Hassan Ait-Kaci Ilog, Canada Maria Alpuente Tech. University Valencia, Spain Thomas Arts IT-Univ. i Goteborg, Sweden Demis Ballis Universita Udine, Italy Josh Berdine Microsoft Research, UK Lubos Brim Masarykova Univ., Czech Republic Darren Cofer Rockwell Collins, USA Byron Cook Microsoft Research, UK Patrick Cousot Ecole Normale Superieure, France Santiago Escobar Tech. University Valencia, Spain Azadeh Farzan University of Toronto, Canada Hubert Garavel INRIA Rhone-Alpes, France Stefania Gnesi ISTI-CNR, Italy Alexey Gotsman University of Cambridge, UK Holger Hermanns Universitat Saarlandes, Germany Christophe Joubert Tech. University Valencia, Spain Daniel Kroening ETH Zurich, Switzerland Michael Leuschel Universitat Dusseldorf, Germany Pedro Merino Universidad de Malaga, Spain Juan Jose Moreno-Navarro Univ. Politecnica Madrid, Spain Corina Pasareanu NASA Ames Research Center, USA Jaco van de Pol Univ. Twente, The Netherlands Murali Rangarajan Honeywell, USA Jakob Rehof Tech. Univ. Dortmund, Germany Andrey Rybalchenko Max-Planck-Gesellschaft, Germany Marcel Verhoef Chess, The Netherlands Martin Wirsing Universitat Munchen, Germany Hongseok Yang University of London, UK Greta Yorsh IBM Watson Research Center, USA ERCIM FMICS WG COORDINATOR -------------------------- Alessandro Fantechi Univ. Firenze, ISTI-CNR, Italy WORKSHOP CHAIR -------------- Christophe Joubert Tech. University Valencia, Spain PAPER SUBMISSIONS ----------------- Submissions must be made electronically through the EasyChair system. Papers should be up to 16 pages in LNCS format, with the names and affiliations of the authors and a clear and informative abstract. Additional details may be included in a clearly marked appendix, which will be read at the discretion of the program committee. All submissions must report on original research. Submitted papers must not have previously appeared in a journal or conference with published proceedings and must not be concurrently submitted to any other peer-reviewed workshop, symposium, conference or archival journal. Any partial overlap with any such published or concurrently submitted paper must be clearly indicated. Case study papers should identify lessons learned, validate theoretical results (such as scalability of methods), or provide specific motivation for further research and development. The workshop proceedings will be published in the Springer series Lecture Notes in Computer Science (LNCS). CO-LOCATION ----------- FMICS 2009 is part of the first Formal Methods Week (FMweek), which will bring together a choice of events in the area, including TESTCOM/FATES (Conference on Testing of Communicating Systems and Workshop on Formal Approaches to Testing of Software), FACS (Formal Aspects of Component Software), PDMC (Parallel and Distributed Methods of verifiCation), FM2009 (Symposium of Formal Methods Europe), CPA (Communicating Process Architectures), FAST (Formal Aspects of Security and Trust), FMCO (Formal Methods for Components and Objects), and the REFINE Workshop. For the latest information on FMweek, see http://www.win.tue.nl/fmweek. ************************************************************ * * * +============================================+ * * | | * * | ** FMweek ** | * * | | * * +============================================+ * * | CPA | FACS | FAST | * * +--------------------------------------------+ * * | FM2009 | FMCO | FMICS | * * +--------------------------------------------+ * * | PDMC | REFINE | TESTCOM/FATES | * * +--------------------------------------------+ * * | http://www.win.tue.nl/fmweek | * * +============================================+ * * * ************************************************************ From byorgey at seas.upenn.edu Sat Mar 28 11:43:59 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Mar 28 11:31:45 2009 Subject: [Haskell] Haskell Weekly News: Issue 111 - March 28, 2009 Message-ID: <20090328154359.GA11166@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090328 Issue 111 - March 28, 2009 --------------------------------------------------------------------------- Welcome to issue 111 of HWN, a newsletter covering developments in the [1]Haskell community. Announcements CHP package. Neil Brown [2]announced the release of version 1.2.0 of the [3]CHP library (which supports explicit message-passing concurrency in Haskell), with various bug-fixes and a new "clock" synchronisation primitive. smartword 0.0.0.5 Web based flash card for Word Smart I and II vocabularies. Ki Yung Ahn [4]announced the release of [5]smartword 0.0.0.5, a web based flash card system for Word Smart I and II, a popular book series for studying GRE vocabularies. HackMail 0.0 -- Procmail + Monads = Awesome!. Joe Fredette [6]announced his very second Hackage upload, [7]HackMail. Hackmail is a Procmail-alike, though it doesn't (yet) support procmail syntax. It dynamically loads a haskell source file and then sits as a daemon watching a directory for new emails. The source file contains a function which sorts email and delivers it to some directory. FallingBlocks 0.1. Ben Sanders [8]announced [9]fallingblocks, a Tetris clone using SDL. io-capture-0.2 capturing std(out|err) in IO action. Yusaku Hashimoto [10]announced the release of [11]io-capture 0.2, a library to capture stdout and stderr in an IO action. It exports a function capture, which takes an IO action and a String representing the entire input, and returns Strings representing the data written to stdout and stderr. wxAsteroids 1.0. Henk-Jan van Tuyl [12]announced [13]wxAsteroids, a game demonstrating the wxHaskell GUI. The votes are in!. Eelco Lempsink [14]announced that the [15]results of the Haskell logo competition are in! Congratulations to Jeff Wheeler on his winning design. Making videos of your project. Don Stewart [16]described how to create short screencasts showing off your latest awesome Haskell project. WinGhci, a GUI for GHCI on Windows. Pepe Gallardo [17]announced the first release of [18]WinGhci, a simple GUI for GHCI on Windows. It is closely based on WinHugs, and provides similar functionality. hranker: Basic utility for ranking a list of items (e.g. for the logo poll). Robin Green [19]announced [20]hranker, a command-line utility that helps the user rank a list of items (of any type implementing Show, Eq and Ord). The hope is that the code is sufficiently clear that it could also serve as an educational piece of code, especially for people wanting to learn how to use the HCL library. salvia-0.1, salvia-extras-0.1. Sebastiaan Visser [21]announced a new version of [22]Salvia, a lightweight Haskell Web Server Framework. Changes in this release include easier dependencies, some new default handler environments that simplify setting up a server application, support for keep-alive, a great deal of additional documentation, support for Windows, and various cleanup and bug fixes. Haddock 2.4.2. David Waern [23]announced a new release of [24]Haddock, the Haskell documentation tool. This is a bug fix release only, and it's the same version that will ship with GHC 6.10.2, unless any important problems are discovered before the GHC release. Because the .haddock file format has changed, links to previously installed documentation will not work when generating documentation using this version. ansi-terminal, ansi-wl-pprint - ANSI terminal support for Haskell. Max Bolingbroke [25]announced the [26]ansi-terminal and [27]ansi-wl-pprint packages, which allow Haskell programs to produce much richer console output by allowing colorisation, emboldening and so on. Both Unix-like (OS X, Linux) and Windows operating systems are supported (via a pure Haskell ANSI emulation layer for Windows). I/O library for Windows. Felix Martini [28]announced the [29]package, an I/O library for Windows using Windows API functions with I/O completion port support. The main goal of this library is to support Simon Marlow's new Handle API once he has added that to GHC. The library also has a compatibility module for socket functions from the network-bytestring package. Discussion Grouping - Map / Reduce. G?nther Schmidt [30]asked about a way to lazily group an unordered list of key/value pairs, leading to some interesting solutions and discussion of preserving laziness. about Haskell code written to be "too smart". Manlio Perillo began an [31]epic discussion about Haskell coding style, idioms, pedagogy, and much, much more. Blog noise [32]Haskell news from the [33]blogosphere. * >>> : [34]I18n and Haskell. Internationalization of Haskell programs. * Holumbus: [35]Holumbus-Distribution Update. * Roman Cheplyaka: [36]Recent activity. Ongoing Hpysics development. * Jason Dagit: [37]Type-Correct Changes---A Safe Approach to Version Control Implementation. Jason is now a Master of Computer Science. * Sebastian Fischer: [38]Fair conjunction and disjunction. * Luke Palmer: [39]Certificate Design Pattern. * >>> Daniel Burrows: [40]Sometimes, tools are useful.. * GHC / OpenSPARC Project: [41]Pinning threads to cores. * Galois, Inc: [42]One Million Haskell Downloads.... * Thomas M. DuBuisson: [43]Yet another proposal for Haskell - the ever growing language. * Christopher Lane Hinson: [44]Twilight Hero. * Xmonad: [45]xmonad download statistics. * LHC Team: [46]Ease of implementation.. * Darcs: [47]darcs weekly news #22. * Well-Typed.Com: [48]Regression testing with Hackage. * Neil Mitchell: [49]Concise Generic Queries. * >>> Vo Minh Thu: [50]First stab at Template Haskell. * >>> Nax: [51]HStringTemplate. Quotes of the Week * ddarius: fmap: Because getting functions to the values is half the battle. * monochrom: Monad is about postmodernism. There are laws but no one owns them. You can interpret them any way you want. You can write about your own understanding and the meaning of your writing is not fixed. * conal: Recursion is the goto of functional programming * monochrom: "Monad is about computation." "Our company is about synergy." "iPod is about coolness." Godawful postmodernism nothingness. * olsner: nah, SkyNet is just a zygohistomorphic prepromorphism, nothing fancy * vixey: put some restriction like every token has a neighbourhood locally homeomophic to algol * gwern: Unfortunately Neo, no one can be *told* what the Monad is. About the Haskell Weekly News New editions are posted to [52]the Haskell mailing list as well as to [53]the Haskell Sequence and [54]Planet Haskell. [55]RSS is also available, and headlines appear on [56]haskell.org. To help create new editions of this newsletter, please see the information on [57]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [58]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://blogs.kent.ac.uk/crg-group/2009/03/chp-120-now-with-clocks/ 3. http://www.cs.kent.ac.uk/projects/ofa/chp/ 4. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55899 5. http://kyagrd.dyndns.org/~kyagrd/project/smartword/ 6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55851 7. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HackMail 8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55812 9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fallingblocks 10. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55786 11. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/io%2Dcapture 12. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55783 13. http://www.haskell.org/haskellwiki/wxAsteroids 14. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55500 15. http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?num_winners=1&id=E_d21b0256a4fd5ed7&algorithm=beatpath 16. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55495 17. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55446 18. http://code.google.com/p/winghci/ 19. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55434 20. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hranker 21. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55424 22. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/salvia 23. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55345 24. http://www.haskell.org/haddock/ 25. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55324 26. http://batterseapower.github.com/ansi-terminal/ 27. http://batterseapower.github.com/ansi-wl-pprint/ 28. http://article.gmane.org/gmane.comp.lang.haskell.cafe/55322 29. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/winio 30. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/55579 31. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/55539 32. http://planet.haskell.org/ 33. http://haskell.org/haskellwiki/Blog_articles 34. http://progandprog.blogspot.com/2009/03/i18n-and-haskell.html 35. http://holumbus.fh-wedel.de/blog/?p=21 36. http://physics-dph.blogspot.com/2009/03/recent-activity.html 37. http://blog.codersbase.com/2009/03/25/type-correct-changes-a-safe-approach-to-version-control-implementation/ 38. http://www-ps.informatik.uni-kiel.de/~sebf/projects/fair-predicates.html 39. http://lukepalmer.wordpress.com/2009/03/24/certificate-design-pattern/ 40. http://algebraicthunk.net/~dburrows/blog/entry/sometimes-tools-are-useful/ 41. http://ghcsparc.blogspot.com/2009/03/pinning-threads-to-cores.html 42. http://www.galois.com/blog/2009/03/23/one-million-haskell-downloads/ 43. http://tommd.wordpress.com/2009/03/22/yet-another-proposal-for-haskell-the-ever-growing-language/ 44. http://blog.downstairspeople.org/2009/03/22/twilight-hero/ 45. http://xmonad.wordpress.com/2009/03/22/xmonad-download-statistics/ 46. http://lhc-compiler.blogspot.com/2009/03/ease-of-implementation.html 47. http://blog.darcs.net/2009/03/darcs-weekly-news-22.html 48. http://blog.well-typed.com/2009/03/regression-testing-with-hackage/ 49. http://neilmitchell.blogspot.com/2009/03/concise-generic-queries.html 50. http://thu.selfip.org/entry/first-stab-th.html 51. http://nax.is-a-geek.net/blog/entries/10/hstringtemplate 52. http://www.haskell.org/mailman/listinfo/haskell 53. http://sequence.complete.org/ 54. http://planet.haskell.org/ 55. http://sequence.complete.org/node/feed 56. http://haskell.org/ 57. http://haskell.org/haskellwiki/HWN 58. http://code.haskell.org/~byorgey/code/hwn/ From conal at conal.net Sat Mar 28 17:53:48 2009 From: conal at conal.net (Conal Elliott) Date: Sat Mar 28 17:41:34 2009 Subject: [Haskell] Re: [Haskell-cafe] Haskell Weekly News: Issue 111 - March 28, 2009 In-Reply-To: <20090328154359.GA11166@seas.upenn.edu> References: <20090328154359.GA11166@seas.upenn.edu> Message-ID: > > conal: Recursion is the goto of functional programming > BTW, I certainly did not mean to take credit for this wonderful quote. I don't know the origin. I first heard it from Erik Meijer. - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090328/1b3db3c2/attachment.htm From gtener at gmail.com Sat Mar 28 19:20:12 2009 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Sat Mar 28 19:07:54 2009 Subject: [Haskell] Re: [Haskell-cafe] Haskell Weekly News: Issue 111 - March 28, 2009 In-Reply-To: References: <20090328154359.GA11166@seas.upenn.edu> Message-ID: <220e47b40903281620l5f2ace06ub057c48bd133aaa3@mail.gmail.com> This paper from 1994: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.5611 begins point 1.1 with exactly that sentence. It doesn't seem to be quoted there, so one can assume this is the original source of that sentence. I'm not sure dough. Regards Christopher Skrz?tnicki 2009/3/28 Conal Elliott : >> conal: Recursion is the goto of functional programming > > BTW, I certainly did not mean to take credit for this wonderful quote.? I > don't know the origin.? I first heard it from Erik Meijer. > > ? - Conal > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From lennart at augustsson.net Sat Mar 28 19:39:59 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sat Mar 28 19:27:21 2009 Subject: [Haskell] Re: [Haskell-cafe] Haskell Weekly News: Issue 111 - March 28, 2009 In-Reply-To: <220e47b40903281620l5f2ace06ub057c48bd133aaa3@mail.gmail.com> References: <20090328154359.GA11166@seas.upenn.edu> <220e47b40903281620l5f2ace06ub057c48bd133aaa3@mail.gmail.com> Message-ID: The quote has been around since at least the early 80s, but I don't know who it's from. 2009/3/28 Krzysztof Skrz?tnicki : > This paper from 1994: > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.5611 > begins point 1.1 with exactly that sentence. It doesn't seem to be > quoted there, so one can assume this is the original source of that > sentence. I'm not sure dough. > > Regards > > Christopher Skrz?tnicki > > 2009/3/28 Conal Elliott : >>> conal: Recursion is the goto of functional programming >> >> BTW, I certainly did not mean to take credit for this wonderful quote.? I >> don't know the origin.? I first heard it from Erik Meijer. >> >> ? - Conal >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ajb at spamcop.net Sat Mar 28 20:45:26 2009 From: ajb at spamcop.net (ajb@spamcop.net) Date: Sat Mar 28 20:32:48 2009 Subject: [Haskell] Re: [Haskell-cafe] Haskell Weekly News: Issue 111 - March 28, 2009 In-Reply-To: <220e47b40903281620l5f2ace06ub057c48bd133aaa3@mail.gmail.com> References: <20090328154359.GA11166@seas.upenn.edu> <220e47b40903281620l5f2ace06ub057c48bd133aaa3@mail.gmail.com> Message-ID: <20090328204526.57y8e8rcg0wcggwk-nwo@webmail.spamcop.net> G'day all. Quoting Krzysztof Skrz?tnicki : > This paper from 1994: > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.5611 > begins point 1.1 with exactly that sentence. It doesn't seem to be > quoted there, so one can assume this is the original source of that > sentence. I'm not sure dough. I always it was a resynthesised version of this: "Procedure calls are, from a theoretical point of view, glorified GOTO statements." -- Guy Steele, "Lambda: The Ultimate GOTO" Cheers, Andrew Bromage From lennart at augustsson.net Sun Mar 29 05:16:40 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Mar 29 05:04:18 2009 Subject: [Haskell] ANN: cmonad 0.1.1 Message-ID: I've uploaded my CMonad package to Hackage. It allows you to write Haskell code in a C style. Unfortunately, GHC lacks certain optimizations to make efficient code when using CMonad, so instead of C speed you get low speed. Example: Computing some Fibonacci numbers: fib = do { a <- arrayU[40]; i <- auto 0; a[0] =: 1; a[1] =: 1; for (i =: 2, (i :: EIO Int) < 40, i += 1) $ do { a[i] =: a[i-1] + a[i-2]; }; retrn (a[39]); } Example: Copying stdin to stdout: cat = do { c <- auto 0; while ((c =: getchar()) >= 0) $ do { putchar(c); }; return (); } -- Lennart From jason.dusek at gmail.com Sun Mar 29 10:13:00 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Mar 29 10:00:41 2009 Subject: [Haskell] Re: [Haskell-cafe] ANN: cmonad 0.1.1 In-Reply-To: References: Message-ID: <42784f260903290713o3ba26dei9aadb7abdf3a8c01@mail.gmail.com> 2009/03/29 Lennart Augustsson : > ...GHC lacks certain optimizations to make efficient code when > using CMonad, so instead of C speed you get low speed. Is this surprising to anyone? -- Jason Dusek From lennart at augustsson.net Sun Mar 29 12:06:51 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Mar 29 11:54:32 2009 Subject: [Haskell] Re: [Haskell-cafe] ANN: cmonad 0.1.1 In-Reply-To: <42784f260903290713o3ba26dei9aadb7abdf3a8c01@mail.gmail.com> References: <42784f260903290713o3ba26dei9aadb7abdf3a8c01@mail.gmail.com> Message-ID: Well, yes and no. GHC actually does a decent job when given very imperative code with references and mutable arrays. Now the type I use to wrap the references to get type safe l-values and r-values makes it tricker, and ghc lacks a crucial optimization for specialization of constructor returns. With that in place I think the code could be quite performant. -- Lennart On Sun, Mar 29, 2009 at 3:13 PM, Jason Dusek wrote: > 2009/03/29 Lennart Augustsson : >> ...GHC lacks certain optimizations to make efficient code when >> using CMonad, so instead of C speed you get low speed. > > ?Is this surprising to anyone? > > -- > Jason Dusek > From dons at galois.com Sun Mar 29 22:28:56 2009 From: dons at galois.com (Don Stewart) Date: Sun Mar 29 22:17:59 2009 Subject: [Haskell] Re: [Haskell-cafe] ANN: cmonad 0.1.1 In-Reply-To: References: <42784f260903290713o3ba26dei9aadb7abdf3a8c01@mail.gmail.com> Message-ID: <20090330022856.GA498@whirlpool.galois.com> Nested constructed product returns? Or constructed sums? lennart: > Well, yes and no. GHC actually does a decent job when given very > imperative code with references and mutable arrays. > Now the type I use to wrap the references to get type safe l-values > and r-values makes it tricker, and ghc lacks a crucial optimization > for specialization of constructor returns. > With that in place I think the code could be quite performant. From DekuDekuplex at Yahoo.com Mon Mar 30 01:09:25 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Mon Mar 30 00:57:23 2009 Subject: [Haskell] Re: ANNOUNCE: wxAsteroids 1.0 References: Message-ID: On Fri, 27 Mar 2009 15:34:06 +0100, "Henk-Jan van Tuyl" wrote: >On Thu, 26 Mar 2009 20:41:57 +0100, Henk-Jan van Tuyl >wrote: > >> >> Your space ship enters an asteroid belt, try to avoid >> collisions! >> >> wxAsteroids is a game demonstrating the wxHaskell GUI. >> >> More about this at: >> http://www.haskell.org/haskellwiki/wxAsteroids > >Maybe I should add more informationn to this: > >The main purpose of this game is to learn how to use wxHaskell; it >also shows, in the main function, how a cabalized program can find its >data files. > >I don't want to take the credit for this program; I took the source code >and images from the paper: > wxHaskell - A Portable and Concise GUI Library for Haskell [1] >by Daan Leijen. If you want to learn how to use wxHaskell, I can advise >you to read this paper. > >Daan gave me permission to publish the code with a BSD license. > >[1] http://legacy.cs.uu.nl/daan/download/papers/wxhaskell.pdf This sounds entertaining, but according to the HaskellWiki entry for GuiTV (see http://haskell.org/haskellwiki/GuiTV), "wxHaskell ... can be difficult to install." Has this difficulty been resolved? I am somewhat hesitant to install wxHaskell because of this reported difficulty. Has anybody had any recent difficulties in installing this package combination on Windows XP Professional, Service Pack 2? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From v.dijk.bas at gmail.com Mon Mar 30 09:30:55 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Mon Mar 30 09:18:32 2009 Subject: [Haskell] Re: [Haskell-cafe] ANN: cmonad 0.1.1 In-Reply-To: References: Message-ID: On Sun, Mar 29, 2009 at 11:16 AM, Lennart Augustsson wrote: > I've uploaded my CMonad package to Hackage. ?It allows you to write > Haskell code in a C style. Nice! A nice addition would be to output a C AST from language-c: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/language-c regards, Bas From nikhil at bluespec.com Mon Mar 30 11:18:35 2009 From: nikhil at bluespec.com (Rishiyur Nikhil) Date: Mon Mar 30 11:05:53 2009 Subject: [Haskell] Re: [Haskell-cafe] Haskell Weekly News: Issue 111 - March 28, 2009 Message-ID: <867033cd0903300818u2a76d360raa120ad96d628dc4@mail.gmail.com> Speaking of lambdas and gotos, some of you may remember the great Professor Eiichi Goto of Japan. You can see an obituary at: http://www.sigsam.org/bulletin/articles/153/goto.pdf He was one of the Japanese pioneers of Lisp, symbolic computing, and architectural support for symbolic computing. He was one of the developers of "hash-consing". He used to joke about his own name, along the lines of: "I'm considered harmful. They're all trying to get rid of me." Nikhil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090330/d2718bcf/attachment.htm From duncan.coutts at worc.ox.ac.uk Tue Mar 31 05:55:08 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Mar 31 05:42:17 2009 Subject: [Haskell] Haskell Platform: status update and call for volunteers Message-ID: <1238493308.25888.1236.camel@localhost> All, We'd like to give you an update on the status of the Haskell Platform. Background ---------- For background on what the Haskell Platform is about see these slides: http://blog.well-typed.com/wp-content/uploads/2008/11/haskell-platform.pdf The wiki page also gives an overview and links to further resources: http://www.haskell.org/haskellwiki/Haskell_Platform Current status -------------- There are no more policy questions to resolve for the first release. It is a matter of getting things done. The first platform release will contain: * ghc-6.10.2 * the "extra libs" (exact list on the issue tracker wiki below) * haddock, happy and alex * the cabal command line tool and it's dependencies. The plan calls for binary installers for Windows and OSX, a generic source tarball for Unix, and native packages for distros. Currently however things are stalled because Don and I have been too busy to put serious time into the task of building installers. It is not fair for our time problems to hold everything up. Call for volunteers ------------------- We are calling for volunteers for an action group. We need volunteers to take charge of various platforms and to manage the overall release. We would like to release a beta at the upcoming Haskell Hackathon in Utrecht (April 17-19). However this will *only* happen if people volunteer to help build distributions for different platforms. In particular we need: * Release manager / coordinator * Website with downloads and release notes * Someone in charge of each platform: * Windows installer * OSX installer * Generic Unix source tarball * Distribution packages: debian, fedora, gentoo, arch, BSD* etc Don and I will be able to help coordinate things and point people in the direction of tasks that need doing. The person in charge of each platform is responsible for building appropriate native packages / installer and coordinating the effort to test that the stuff installs ok and works. If no one volunteers, we simply won't have an Haskell Platform release for that platform. Resources: * Meta-package: darcs get http://code.haskell.org/haskell-platform * Issue tracker: http://trac.haskell.org/haskell-platform/ * Mailing list: http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform Please join the mailing list and volunteer! In the medium term we want to organise things with two overlapping groups. A "doers" group and a "talkers" group. The "doers" group deals with actually building installers and packages and making releases. The "talkers" group is for making decisions (in consultation with the community in general) about which packages go into the platform and what standards to demand of them. We are looking for volunteers for the action group now. As we mentioned, for the first release there is nothing for the talkers to do, though there will be plenty to do for the second major release. Duncan and Don