From matt at mattelder.org Sat Aug 1 15:39:35 2009 From: matt at mattelder.org (Matthew Elder) Date: Sat Aug 1 15:20:52 2009 Subject: [Haskell] ANNOUNCE: sendfile-0.5 with >2gb files and goood performance Message-ID: <987d172d0908011239y281c0438k1fdd5b2dfb55b4c7@mail.gmail.com> sendfile-0.5 -------------------------------------------------------------------------------- * Code simplification / beautification * Fixed a bug where all bytes were not sent with larger files in linux (greater than 5 mb or so) * Added large file support (> 2gb) for Linux, Win32, and Portable * The current handle position will now be ignored in favor of using an offset when using the ' variants. There is no guarantee that an input file Handle will not be mutated; only a guarantee that sendFile' and unsafeSendFile' do not care about the starting position -- they will always start from the beginning. * The portable implementation is now more reliable and memory-efficient thanks to the work done by Bardur Arantsson. * The Win32 implementation is more reliable now, as TransmitFile is now called with 'foreign import stdcall safe' once again. The FreeBSD implementation is still in need of some love but the Win32 & Linux implementations work great! Happy Hacking! Matthew Elder -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090801/43029a42/attachment.html From ifl2009 at shu.edu Sun Aug 2 09:29:39 2009 From: ifl2009 at shu.edu (IFL 2009) Date: Sun Aug 2 09:10:36 2009 Subject: [Haskell] IFL 2009: Call for Papers and Participation Message-ID: An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090802/f301b8ca/attachment.html From nricci01 at eecs.tufts.edu Sun Aug 2 21:24:44 2009 From: nricci01 at eecs.tufts.edu (Nathan Ricci) Date: Sun Aug 2 21:05:38 2009 Subject: [Haskell] memory management Message-ID: <4A763C5C.6080603@eecs.tufts.edu> Hello, I'm interested in research relating to memory management in Haskell. I'm at the point where I don't know enough to have very specific questions, but I'm especially interested in garbage collection in Haskell, and any available statistics (such as, how long does a thunk typically live before its evaluated, after its evaluated?), or tools that would let me get that sort of information more easily. If any one could be so kind as to point me to relevant research papers or other documentation, it would be very much appreciated. --Nathan Ricci From dons at galois.com Sun Aug 2 21:24:12 2009 From: dons at galois.com (Don Stewart) Date: Sun Aug 2 21:07:11 2009 Subject: [Haskell] memory management In-Reply-To: <4A763C5C.6080603@eecs.tufts.edu> References: <4A763C5C.6080603@eecs.tufts.edu> Message-ID: <20090803012412.GN13973@whirlpool.galois.com> nricci01: > Hello, > > I'm interested in research relating to memory management in > Haskell. I'm at the point where I don't know enough to have very > specific questions, but I'm especially interested in garbage collection > in Haskell, and any available statistics (such as, how long does a thunk > typically live before its evaluated, after its evaluated?), or tools > that would let me get that sort of information more easily. If any one > could be so kind as to point me to relevant research papers or other > documentation, it would be very much appreciated. Some research papers on GC and Haskell: http://haskell.org/haskellwiki/Research_papers/Runtime_systems#Garbage_collection Simon Marlow has some recent papers on benchmarking costs in the runtime, http://www.haskell.org/~simonmar/bib/bib.html From florbitous at gmail.com Mon Aug 3 09:12:14 2009 From: florbitous at gmail.com (Bernie Pope) Date: Mon Aug 3 08:53:07 2009 Subject: [Haskell] memory management In-Reply-To: <4A763C5C.6080603@eecs.tufts.edu> References: <4A763C5C.6080603@eecs.tufts.edu> Message-ID: <4d8ad03a0908030612h6f9a6992m664172b7cb3dd41d@mail.gmail.com> 2009/8/3 Nathan Ricci : > Hello, > > ? ? I'm interested in research relating to memory management in Haskell. I'm > at the point where I don't know enough to have very specific questions, but > I'm especially interested in garbage collection in Haskell, and any > available statistics (such as, how long does a thunk typically live before > its evaluated, after its evaluated?), or tools that would let me get that > sort of information more easily. If any one could be so kind as to point me > to relevant research papers or other documentation, it would be very much > appreciated. > > ? ? ? ? ?--Nathan Ricci Hi Nathan, Whilst the work is not about memory management directly, you might find this paper interesting: Feedback Directed Implicit Parallelism Tim Harris and Satnam Singh http://research.microsoft.com/en-us/um/people/tharris/papers/2007-fdip.pdf And maybe have a look at the work on optimistic evaluation in Haskell: Adaptive Evaluation of Non-Strict Programs (PhD thesis) http://berkeley.intel-research.net/rennals/ (there might be some analysis about the life of thunks in those references). Cheers, Bernie. From padl.2010.cfp at gmail.com Mon Aug 3 12:08:33 2009 From: padl.2010.cfp at gmail.com (PADL 2010) Date: Mon Aug 3 11:49:27 2009 Subject: [Haskell] PADL 2010: Second Call for Papers Message-ID: <51fc5ca20908030908k1e30f85dh3a552c0c498609bc@mail.gmail.com> CALL FOR PAPERS Twelfth International Symposium on Practical Aspects of Declarative Languages 2010 (PADL'10) http://clip.dia.fi.upm.es/Conferences/PADL-2010 Madrid, Spain January 18-19, 2010 Co-located with ACM POPL'10 Declarative languages build on sound theoretical bases to provide attractive frameworks for application development. These languages have been successfully applied to many different real-world situations, ranging from data base management to active networks to software engineering to decision support systems. New developments in theory and implementation have opened up new application areas. At the same time, applications of declarative languages to novel problems raise numerous interesting research issues. Well-known questions include designing for scalability, language extensions for application deployment, and programming environments. Thus, applications drive the progress in the theory and implementation of declarative systems, and benefit from this progress as well. PADL is a forum for researchers and practitioners to present original work emphasizing novel applications and implementation techniques for all forms of declarative concepts, including, functional, logic, constraints, etc. Topics of interest include, but are not limited to: * Innovative applications of declarative languages. * Declarative domain-specific languages and applications. * Practical applications of theoretical results. * New language developments and their impact on applications. * Declarative languages and Software Engineering. * Evaluation of implementation techniques on practical applications. * Practical experiences and industrial applications. * Novel uses of declarative languages in the classroom. PADL'10 welcomes new ideas and approaches pertaining to applications and implementation of declarative languages. PADL'10 will be co-located with POPL 2010. IMPORTANT DATES Abstract submission: August 31, 2009 Paper Submission: September 4, 2009 Notification: October 5, 2009 Camera-ready: October 26, 2009 Symposium: January 18-19, 2010 SUBMISSION GUIDELINES Authors should submit an electronic copy of the full paper (written in English) in PDF, in the Springer LNCS format (see http://www.springer.com/computer/lncs?SGWID=0-164-7-72376-0). The submission will be done through EasyChair at the URL http://www.easychair.org/conferences/?conf=padl10 . PADL'10 will accept both technical and application papers. Technical Papers Technical papers must describe original, previously unpublished research results, and must not be simultaneously submitted for publication elsewhere. Each submission must be written in English, and include three to four keywords, which will be used to assist us in selecting appropriate reviewers for the paper. Submissions must not exceed 15 pages in Springer LNCS format. Application Papers Application papers are a mechanism to present important practical applications of declarative languages that occur in industry or in areas of research other than computer science. Application papers will be published in the Springer-Verlag conference proceedings, and will be presented in a separate session. Application papers are expected to describe complex and/or real-world applications that rely on an innovative use of declarative languages. Application descriptions, engineering solutions and real-world experiences (both positive and negative) are solicited. The limit for application papers is 3 pages in Springer LNCS format. Most Practical Paper Award The Most Practical Paper award will be given to the technical submission that is judged by the program committee to be the best in terms of practicality, originality, and clarity of presentation. The program committee may choose not to make an award, or to make multiple awards. PROGRAM COMMITTEE Program Committee Chairs Manuel Carro (Universidad Polit?cnica de Madrid, Spain) Ricardo Pe?a (Universidad Complutense de Madrid, Spain) Program Committee Mar?a Alpuente (Universidad Polit?cnica de Valencia, Spain) Lennart Augustson (Standard Chartered Bank and Chalmers University of Technology, Sweden) Olaf Chitil (University of Kent, UK) Mar?a Garc?a de la Banda (Monash University, Australia) Andy Gill (The University of Kansas, USA) Haifeng Guo (University of Nebraska at Omaha, USA) Martin Hofmann (Ludwig-Maximilians Universit?t, Germany) Andy King (Portcullis Computer Security Limited, UK) John Launchbury (Galois, USA) Rita Loogen (Philipps-Universit?t Marburg, Germany) Erik Meijer (Microsoft Research, UK) Enrico Pontelli (New Mexico State University, USA) V?tor Santos Costa (Universidade do Porto, Portugal) Terrance Swift (CENTRIA, Portugal) Paolo Torroni (Universit? di Bologna, Italy) Roland Yap (National University of Singapore, Singapore) CONTACTS: For information about papers and submissions, please contact a Program Chair: Manuel Carro PC co-Chair - PADL 2010 School of Computer Science Universidad Polit?cnica de Madrid Campus de Montengancedo E-28660 Boadilla del Monte, Spain Email: mcarro fiupmes Ricardo Pe?a PC co-Chair - PADL 2010 Facultad de Inform?tica Universidad Complutense de Madrid c/ Profesor Jos? Garc?a Santesmases s/n E-28040 Madrid, Spain Email: ricardo sipucmes For other information about the conference, please contact: Manuel Carro General Chair - PADL 2010 School of Computer Science Universidad Polit?cnica de Madrid Campus de Montengancedo E-28660 Boadilla del Monte, Spain Email: mcarro fiupm.es WITH THE COOPERATION OF: The University of Texas at Dallas ACM Sigplan From colin at cs.york.ac.uk Tue Aug 4 07:05:52 2009 From: colin at cs.york.ac.uk (Colin Runciman) Date: Tue Aug 4 06:50:38 2009 Subject: [Haskell] memory management In-Reply-To: <4A763C5C.6080603@eecs.tufts.edu> References: <4A763C5C.6080603@eecs.tufts.edu> Message-ID: <4A781610.9030308@cs.york.ac.uk> Nathan, > I'm interested in research relating to memory management in > Haskell. I'm at the point where I don't know enough to have very > specific questions, but I'm especially interested in garbage collection > in Haskell, and any available statistics (such as, how long does a thunk > typically live before its evaluated, after its evaluated?), or tools > that would let me get that sort of information more easily. If any one > could be so kind as to point me to relevant research papers or other > documentation, it would be very much appreciated. In the early to mid '90s we built various heap-profiling tools to examine the characteristics of heap data in lazy functional programs. You can find papers describing this work by Googling "heap profiling". You may be particularly interested in the investigation of "heap lag" and "heap drag" -- see for example the ICFP'96 paper. Others have worked on similar tools since, but I'm not sure how extensive heap profiling facilities are in ghc, the most widely used implementation of Haskell. Regards Colin R From sam.martin at geomerics.com Tue Aug 4 07:30:02 2009 From: sam.martin at geomerics.com (Sam Martin) Date: Tue Aug 4 07:12:07 2009 Subject: [Haskell] memory management In-Reply-To: <4A781610.9030308@cs.york.ac.uk> References: <4A763C5C.6080603@eecs.tufts.edu> <4A781610.9030308@cs.york.ac.uk> Message-ID: I'm not quite sure how to describe this, but are you aware of any research into converting heap allocations into frames on a stack? For example, many C functions follow this kind of pattern: void doSomeStuff(..) { // allocate required resources int a,b,c; // finite amount of temp allocations on stack int* buffer = malloc(..); // larger (finite) allocation on heap // free resources free(buffer); // free heap allocations // stack allocs popped by compiler. } They key aspect is the amount of memory required is calculatable in advance and allocated/removed in a lump rather than a series of requests. No pointer-tracking/garbage collection is required. I can picture similar situations arising in Haskell where for suitable expressions the compiler could in theory determine that garbage collection would be unnecessary for a lump of temporary data and simply allocate/deallocate when starting/finishing evaluating the thunk. The goal being to simplify garbage collection for this kind of temporary allocation. Any thoughts? Ta, Sam -----Original Message----- From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Colin Runciman Sent: 04 August 2009 12:06 To: Nathan Ricci Cc: Haskell@haskell.org Subject: Re: [Haskell] memory management Nathan, > I'm interested in research relating to memory management in > Haskell. I'm at the point where I don't know enough to have very > specific questions, but I'm especially interested in garbage collection > in Haskell, and any available statistics (such as, how long does a thunk > typically live before its evaluated, after its evaluated?), or tools > that would let me get that sort of information more easily. If any one > could be so kind as to point me to relevant research papers or other > documentation, it would be very much appreciated. In the early to mid '90s we built various heap-profiling tools to examine the characteristics of heap data in lazy functional programs. You can find papers describing this work by Googling "heap profiling". You may be particularly interested in the investigation of "heap lag" and "heap drag" -- see for example the ICFP'96 paper. Others have worked on similar tools since, but I'm not sure how extensive heap profiling facilities are in ghc, the most widely used implementation of Haskell. Regards Colin R _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell From gwern0 at gmail.com Tue Aug 4 07:39:45 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Tue Aug 4 07:20:38 2009 Subject: [Haskell] memory management In-Reply-To: Message-ID: On Tue, Aug 4, 2009 at 7:30 AM, Sam Martin wrote: > I can picture similar situations arising in Haskell where for suitable > expressions the compiler could in theory determine that garbage > collection would be unnecessary for a lump of temporary data and simply > allocate/deallocate when starting/finishing evaluating the thunk. The > goal being to simplify garbage collection for this kind of temporary > allocation. > > Any thoughts? > > Ta, > Sam Sounds like region inference to me. (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) -- gwern -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20090804/e6b31251/signature.bin From sam.martin at geomerics.com Tue Aug 4 08:33:48 2009 From: sam.martin at geomerics.com (Sam Martin) Date: Tue Aug 4 08:15:54 2009 Subject: [Haskell] memory management In-Reply-To: References: Message-ID: > Sounds like region inference to me. > (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) Thanks, yes, that's exactly what I had in mind. Is anything like this is done in GHC? Ta, Sam From marlowsd at gmail.com Tue Aug 4 09:49:40 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Aug 4 09:30:31 2009 Subject: [Haskell] memory management In-Reply-To: References: Message-ID: <4A783C74.1@gmail.com> On 04/08/2009 13:33, Sam Martin wrote: >> Sounds like region inference to me. >> (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) > > Thanks, yes, that's exactly what I had in mind. > > Is anything like this is done in GHC? Not at the moment, no. Bear in mind that with generational GC, allocating memory that quickly becomes garbage is quite cheap. Cheers, Simon From sigbjorn.finne at gmail.com Tue Aug 4 10:11:09 2009 From: sigbjorn.finne at gmail.com (Sigbjorn Finne) Date: Tue Aug 4 09:52:18 2009 Subject: [Haskell] memory management In-Reply-To: <4A783C74.1@gmail.com> References: <4A783C74.1@gmail.com> Message-ID: <4A78417D.2040905@gmail.com> Hi, staying in the realm of the explicit and pragmatic, various libraries in Haskell do provide safe&explicit region/alloca/stack allocation actions, e.g., Foreign.Marshal.Alloc.allocaBytes :: Int -> (Ptr a -> IO b) -> IO b with the promise that the pointer doesn't escape here (you could constrain this using the type system, if you so wish..) I don't know if the GHC RTS still(?) provides hooks for allocating "alloca" objects specially. There's been some work on monadic regions too; worth looking at. hth --sigbjorn On 8/4/2009 15:49, Simon Marlow wrote: > On 04/08/2009 13:33, Sam Martin wrote: >>> Sounds like region inference to me. >>> (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) >> >> Thanks, yes, that's exactly what I had in mind. >> >> Is anything like this is done in GHC? > > Not at the moment, no. > > Bear in mind that with generational GC, allocating memory that quickly > becomes garbage is quite cheap. > > Cheers, > Simon > From sebastian.sylvan at gmail.com Tue Aug 4 10:15:21 2009 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Tue Aug 4 09:56:12 2009 Subject: [Haskell] memory management In-Reply-To: <4A783C74.1@gmail.com> References: <4A783C74.1@gmail.com> Message-ID: <3d96ac180908040715w59d1717bs8fcfdb632557fe7@mail.gmail.com> On Tue, Aug 4, 2009 at 2:49 PM, Simon Marlow wrote: > On 04/08/2009 13:33, Sam Martin wrote: > >> Sounds like region inference to me. >>> (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) >>> >> >> Thanks, yes, that's exactly what I had in mind. >> >> Is anything like this is done in GHC? >> > > Not at the moment, no. > > Bear in mind that with generational GC, allocating memory that quickly > becomes garbage is quite cheap. > Speculation time... I have no real basis for this, and I'm quite possibly overlooking a lot of details... There may be other benefits to doing this kind of escape-analysis, aside from making short-lived allocations cheaper (which are indeed already quite cheap)... If you can associate a bunch of allocations with a point in the stack, even if it's very low in the stack (and thus long-lived), there's a lot less work that the GC needs to do to track all the other allocations (in the global heap), since there's just fewer of them. Also, each stack is associated with a specific thread, so it sort of brings you half-way to per-thread GC, in the sense that all the stack-based resource management is per-thread. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090804/7e63a169/attachment.html From bulat.ziganshin at gmail.com Tue Aug 4 12:14:26 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Aug 4 12:04:19 2009 Subject: [Haskell] memory management In-Reply-To: <4A78417D.2040905@gmail.com> References: <4A783C74.1@gmail.com> <4A78417D.2040905@gmail.com> Message-ID: <1157670850.20090804201426@gmail.com> Hello Sigbjorn, Tuesday, August 4, 2009, 6:11:09 PM, you wrote: > this using the type system, if you so wish..) I don't know if the GHC > RTS still(?) provides hooks for allocating "alloca" objects specially. it's allocated as usual object, these are cheap anyway as far as it freed before minor GC occurs (which is called after each 512kb allocated, by default) afair, jhc uses region inference -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From will.donnelly at gmail.com Thu Aug 6 01:22:26 2009 From: will.donnelly at gmail.com (Will Donnelly) Date: Thu Aug 6 01:03:11 2009 Subject: [Haskell] ANNOUNCE: Dyre - Dynamic Program Recompilation (Xmonad-style configuration) Message-ID: <6f4294c0908052222n365fe19euc748ea079f51edc2@mail.gmail.com> Dyre is a library for Xmonad-style program recompilation. It is based in spirit after the HConf library written by the Yi project, but with a number of key differences: 1. Focus on simple integration into existing programs. 2. A single program entry point, rather than two. 3. Emphasis on relaunching / state persistence as an *optional* feature. 4. Windows support A reasonably complete explanation, along with a full usage example, is available in the Haddock documentation for the 'Config.Dyre' module, which I unfortunately cannot link to because HackageDB has not yet processed the documentation. The library itself may be found at < http://hackage.haskell.org/package/dyre>. I eagerly await any feedback people have to offer. Thank you for your attention - Will Donnelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090806/0868f9df/attachment.html From simonpj at microsoft.com Thu Aug 6 03:22:33 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Aug 6 03:03:19 2009 Subject: [Haskell] memory management In-Reply-To: <4A783C74.1@gmail.com> References: <4A783C74.1@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C357F321EAE8@EA-EXMSG-C334.europe.corp.microsoft.com> Also region inference is likely to be much less effective in a lazy language, because (I think that) data escapes the lifetime of its allocating procedure much more often. I don't know of any work that has even tried it. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On | Behalf Of Simon Marlow | Sent: 04 August 2009 14:50 | To: Sam Martin | Cc: Colin Runciman; Haskell@haskell.org | Subject: Re: [Haskell] memory management | | On 04/08/2009 13:33, Sam Martin wrote: | >> Sounds like region inference to me. | >> (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) | > | > Thanks, yes, that's exactly what I had in mind. | > | > Is anything like this is done in GHC? | | Not at the moment, no. | | Bear in mind that with generational GC, allocating memory that quickly | becomes garbage is quite cheap. | | Cheers, | Simon | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From simonpj at microsoft.com Thu Aug 6 03:22:37 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Aug 6 03:03:22 2009 Subject: [Haskell] memory management In-Reply-To: <4A781610.9030308@cs.york.ac.uk> References: <4A763C5C.6080603@eecs.tufts.edu> <4A781610.9030308@cs.york.ac.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C357F321EAED@EA-EXMSG-C334.europe.corp.microsoft.com> | In the early to mid '90s we built various heap-profiling tools to | examine the characteristics of heap data in lazy functional programs. | You can find papers describing this work by Googling "heap profiling". | You may be particularly interested in the investigation of "heap lag" | and "heap drag" -- see for example the ICFP'96 paper. Others have | worked on similar tools since, but I'm not sure how extensive heap | profiling facilities are in ghc, the most widely used implementation of | Haskell. GHC has pretty good heap profiling, including lag/drag/void. I hope they are still working smoothly, although I don't think they have received much love recently. Simon From marlowsd at gmail.com Thu Aug 6 04:06:06 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Aug 6 03:46:53 2009 Subject: [Haskell] memory management In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C357F321EAED@EA-EXMSG-C334.europe.corp.microsoft.com> References: <4A763C5C.6080603@eecs.tufts.edu> <4A781610.9030308@cs.york.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C357F321EAED@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4A7A8EEE.5090004@gmail.com> On 06/08/2009 08:22, Simon Peyton-Jones wrote: > | In the early to mid '90s we built various heap-profiling tools to > | examine the characteristics of heap data in lazy functional programs. > | You can find papers describing this work by Googling "heap profiling". > | You may be particularly interested in the investigation of "heap lag" > | and "heap drag" -- see for example the ICFP'96 paper. Others have > | worked on similar tools since, but I'm not sure how extensive heap > | profiling facilities are in ghc, the most widely used implementation of > | Haskell. > > GHC has pretty good heap profiling, including lag/drag/void. I hope they are still working smoothly, although I don't think they have received much love recently. The lag/drag/void stuff (aka biographical profiling) was a bit broken for a while after pointer tagging was introduced, but should be fine now. Cheers, Simon From sam.martin at geomerics.com Thu Aug 6 05:26:03 2009 From: sam.martin at geomerics.com (Sam Martin) Date: Thu Aug 6 05:08:13 2009 Subject: [Haskell] memory management In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C357F321EAE8@EA-EXMSG-C334.europe.corp.microsoft.com> References: <4A783C74.1@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C357F321EAE8@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: I can see how laziness works against this, and agree it's probably not suitable for most lazy code. Generational GC does sound much more appropriate. But fair chunks of Haskell code can be known to be strict. Either from analysis of the code, or explicit instruction by the programmer. (I also have nested data parallelism in the back of my mind for some reason.) I'd risk a bet that these areas of code are probably your 'inner loops' and hence areas a programmer wouldn't want allocation/deallocation to occur unless absolutely necessary. Isn't region inference an attractive option for these situations? Cheers, Sam -----Original Message----- From: Simon Peyton-Jones [mailto:simonpj@microsoft.com] Sent: 06 August 2009 08:23 To: Simon Marlow; Sam Martin Cc: Colin Runciman; Haskell@haskell.org Subject: RE: [Haskell] memory management Also region inference is likely to be much less effective in a lazy language, because (I think that) data escapes the lifetime of its allocating procedure much more often. I don't know of any work that has even tried it. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On | Behalf Of Simon Marlow | Sent: 04 August 2009 14:50 | To: Sam Martin | Cc: Colin Runciman; Haskell@haskell.org | Subject: Re: [Haskell] memory management | | On 04/08/2009 13:33, Sam Martin wrote: | >> Sounds like region inference to me. | >> (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) | > | > Thanks, yes, that's exactly what I had in mind. | > | > Is anything like this is done in GHC? | | Not at the moment, no. | | Bear in mind that with generational GC, allocating memory that quickly | becomes garbage is quite cheap. | | Cheers, | Simon | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From Malcolm.Wallace at cs.york.ac.uk Thu Aug 6 06:08:12 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Aug 6 05:48:58 2009 Subject: [Haskell] bug in language definition (strictness) Message-ID: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> It has been brought to my attention (as errata editor of the revised H'98 report) that there is a bug in the language definition, concerning strictness annotations on datatypes. In section 4.2.1, the translation of strict components of a data constructor is defined as > (\ x1 ... xn -> ( ((K op1 x1) op2 x2) ... ) opn xn) > > where opi is the non-strict apply function $ if si is of the form > ti, and opi is the strict apply function $! (see Section 6.2) if si > is of the form ! ti. Pattern matching on K is not affected by > strictness flags. > yet, because of the definition of $!, this applies the constructor to its arguments right-to-left instead of the intuitive left-to-right. All extant compilers in fact evaluate the strict fields left-to-right in violation of the Report. The same non-intuitive behaviour can be seen more clearly in the simple expression: (f $! x) $! y in which you might expect x to be evaluated before y, but in fact it is the other way round. (And here, the compilers do follow the Report.) The fix I propose for H'98 (and equally for Haskell Prime) is to change the definition of $! as follows Replace f $! x = x `seq` f x with f $! x = f `seq` x `seq` f x in section 6.2 Regards, Malcolm From henglein at diku.dk Thu Aug 6 12:21:05 2009 From: henglein at diku.dk (Fritz Henglein) Date: Thu Aug 6 12:01:49 2009 Subject: [Haskell] Postdoc and Ph.D. position on 3gERP-project at DIKU In-Reply-To: References: Message-ID: A postdoc position and a Ph.D. scholarship are available at the Department of Computer Science, University of Copenhagen (DIKU) within 3d generation enterprise resource planning systems (3gERP), a collaborative strategic research project with partners at DIKU (computer science), Copenhagen Business School (CBS, information systems) and Microsoft Development Center Copenhagen (MDCC, enterprise systems). The 3gERP Project Enterprise software accounts for more than $200 billion in annual global revenue (about 5 times the total revenue of the computer games industry) and costs 10-20 times more than the hardware it runs on. ?The goal of the 3gERP project is to contribute to developing theories, technologies and tools aimed at making enterprise ("ERP") systems more customizable, evolvable and affordable, specifically for small and medium-sized enterprises (SMEs). ? Starting the second project phase this summer the focus is on executable declarative domain-specific languages for bridging the gap from requirements to running code, specifically: ? process specification languages and tools for capturing, managing, and analyzing processes such as contracts, work flows and production schedules; ? reporting languages and incrementalization technology for automatic transformation of business analysis functions to operate in real time in a transactional environment; ? logic-based modeling of legal rules and reasoning in the business domain; ? presentation frameworks/languages for automatically generating role-tailored user interfaces from process, role and data rendering specifications; ? design and implementation of a prototype ERP system based on the Process-Oriented Event-driven Transaction Systems (POETS) software architecture, which encompasses the above components. Ph.D. position We are looking for a Ph.D. student to work on ? reporting languages and incrementalization technology for automatic transformation of business analysis functions to operate in real time in a transactional environment. ?This will include mathematical and computer science studies of incrementalization (transforming batch programs into programs that work online, updating their result continuously as new data arrive), programming of software tools, integration into a prototype enterprise system based on POETS, and real-life evaluation in SMEs in collaboration with project partners at CBS and MDCC. Postdoc position We are looking for a postdoc to work on ? design and implementation of a prototype ERP system based on the Process-Oriented Event-driven Transaction Systems (POETS) software architecture, including process, reporting and rules components in collabortion with the other team members at DIKU, and ? generating role-tailored user interfaces from process, role and data rendering specifications. The candidates should have solid theoretical foundations (such as in strongly typed functional programming; programming language semantics, program analysis, model checking, type systems, logic, process calculi program transformations/model-driven programming) and should preferably feel excited rather than concerned by the prospect of using and developing those foundations for constructing software with a demonstrated potential for practical utility in an application domain that constitutes an large sector of the economy. For more information please see the full position announcement at: http://www.diku.dk/~henglein/3gERP-positions.pdf Fritz Henglein henglein@diku.dk From ekmett at gmail.com Thu Aug 6 14:16:26 2009 From: ekmett at gmail.com (Edward Kmett) Date: Thu Aug 6 13:57:14 2009 Subject: [Haskell] memory management In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C357F321EAE8@EA-EXMSG-C334.europe.corp.microsoft.com> References: <4A783C74.1@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C357F321EAE8@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <7fb8f82f0908061116n6539b150r1cd9fd404940223@mail.gmail.com> Meacham's JHC was headed towards region inference for a while (and may still be), and I spent some time trying to use region inference in a research compiler of my own, and I think both projects effectively came to that same conclusion -- regions and laziness don't mix. Finding useful regions in a lazy language is hard. You can't effectively annotate them in the source due to laziness decoupling object lifetimes from that of your source stack frames, so you need to infer them once you've translated into some strict intermediate representation, and the regions you can infer are finicky and brittle at best. Region-based code optimization in ML tends to center around identifying which region is leaking and why, and without any sort of source code tie for the region system, that becomes a seriously black box. Thunks tend to hold onto lots of context, so minor source changes yield vastly different region profiles. Finally, all of the effort is called into question by the fact that regions alone can't even handle a lot of interesting cases, so you need a collector to boot. Tofte et al. wrote a retrospective at some point basically talking about the now-known limitations of region based memory management [ http://portal.acm.org/citation.cfm?id=993040 , pre-print: http://www.elsman.com/retro.pdf], which I think has the right balance of optimism and pragmatism where it comes to region-based memory management and talks about many of these issues. -Edward Kmett On Thu, Aug 6, 2009 at 3:22 AM, Simon Peyton-Jones wrote: > Also region inference is likely to be much less effective in a lazy > language, because (I think that) data escapes the lifetime of its allocating > procedure much more often. I don't know of any work that has even tried it. > > Simon > > | -----Original Message----- > | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] > On > | Behalf Of Simon Marlow > | Sent: 04 August 2009 14:50 > | To: Sam Martin > | Cc: Colin Runciman; Haskell@haskell.org > | Subject: Re: [Haskell] memory management > | > | On 04/08/2009 13:33, Sam Martin wrote: > | >> Sounds like region inference to me. > | >> (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) > | > > | > Thanks, yes, that's exactly what I had in mind. > | > > | > Is anything like this is done in GHC? > | > | Not at the moment, no. > | > | Bear in mind that with generational GC, allocating memory that quickly > | becomes garbage is quite cheap. > | > | Cheers, > | Simon > | _______________________________________________ > | 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090806/0e43ce0f/attachment-0001.html From byorgey at seas.upenn.edu Sat Aug 8 12:00:31 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Aug 8 11:41:10 2009 Subject: [Haskell] Haskell Weekly News: Issue 127 - August 8, 2009 Message-ID: <20090808160031.GA23392@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090808 Issue 127 - August 08, 2009 --------------------------------------------------------------------------- Welcome to issue 127 of HWN, a newsletter covering developments in the [1]Haskell community. Apologies for the long hiatus, mostly due to organizing Hac phi (which was a [2]great success!). And I'm now going on vacation for a couple weeks and may have limited Internet access, so don't hold your breath for an issue of the HWN next week either... anyway, a ton of interesting stuff has happened over the past three weeks (of course), including a bunch of [3]discussion on the Haskell-prime mailing list, a number of package releases, Haskell Platform discussion, and more. Announcements bindings-posix 0.0.2. Mauricio [4]announced [5]bindings-posix, a low level binding to Posix. It makes use of facilities and design from the [6]bindings-common package to map the [7]standard Posix library. bindings-common 0.2.1. Mauricio [8]announced a new release of [9]bindings-common, which offers basic code that provides a common design standard and common utilities for writing modules providing low-level foreign library bindings. The major new feature of this release is the availability of hsc2hs custom macros, and a corresponding reduction in code size. Dyre - Dynamic Program Recompilation (Xmonad-style configuration). Will Donnelly [10]announced the release of [11]dyre, a library for xmonad-style program recompilation. It is based in spirit after the HConf library written by the Yi project, but with a focus on simple integration, state persistence as an optional feature, and Windows support. nntp 0.0.2. Maciej Piechotka [12]announced the release of [13]nntp, a library to connect to nntp (i.e. mainly USENET) servers. This version represents a complete rewrite from version 0.0.1, including a new NntpT monad and basic support for XHDR. GLUT 2.2.0.0. Sven Panne [14]announced a new version of the [15]GLUT package, which depends on the new OpenGL, StateVar and Tensor packages, but is otherwise unchanged except for a new demo. OpenGL 2.3.0.0. Sven Panne [16]announced a new version of the [17]OpenGL package, which is now only a convenience layer upon the [18]OpenGLRaw and [19]GLURaw packages, written in in pure Haskell without the FFI. The latter two packages load the native libraries dynamically and do not rely on any C headers, making it possible to build all OpenGL-related packages even on machines without any installed native OpenGL support. yices 0.0.0.1. Ki Yung Ahn [20]announced [21]yices, a Haskell interface to the [22]Yices SMT solver. ALUT 2.2.0.0. Sven Panne [23]announced a new version of the ALUT package, which now depends on the highly portable [24]StateVar package instead of [25]OpenGL. OpenAL 1.4.0.0. Sven Panne [26]announced a new version of the [27]OpenAL package, which now depends on the highly portable [28]StateVar, [29]ObjectName and [30]Tensor packages, instead of [31]OpenGL. Tensor 1.0.0.1. Sven Panne [32]announced the [33]Tensor package, yet another spin-off of the OpenGL package, containing a few tensor data types and their instances for some basic type classes. darcs 2.3.0. Petr Rockai [34]announced a new stable release of [35]darcs, version 2.3.0. This version includes a number of improvements and bugfixes over the previous stable release, 2.2. Moreover, work has been done to improve performance of "darcs whatsnew" for large repositories. uacpid-0.0.4. Dino Morelli [36]announced the release of [37]uacpid, a daemon designed to be run in userspace that will monitor the local system's acpid socket for hardware events. These events can then be acted upon by handlers with access to the user's environment. Korean translation of "Programming in Haskell". Ki Yung Ahn [38]announced a new [39]non-English book on Haskell, published on July 24. TABI 0.1: a typeful tagged cross-language calling convention. Bulat Ziganshin [40]announced a preliminary release of [41]TABI, a library providing a typeful, tagged cross-language calling convention. Typeful/Text/HTMLs (for AngloHaskell/for scrap?). Jon Fairbairn [42]announced an [43]HTML library which guarantees standards compliance via types, even down to the nesting restrictions. yst 0.2.1. John MacFarlane [44]announced the release of [45]yst, which generates static websites from YAML or CSV data files and StringTemplates. This approach combines the speed, security, and ease of deployment of a static website with the flexibility and maintainability of a dynamic site that separates presentation and data. The Haskell Platform 2009.2.0.2. Don Stewart [46]announced the third release (2009.2.0.2) of the [47]Haskell Platform, a single, standard Haskell distribution for everyone. atom 0.1.0. Tom Hawkins [48]announced the 0.1.0 release of [49]Atom, a Haskell DSL for hard realtime applications. This release includes support for assertions and functional coverage to aid simulation and testing. tkhs-0.1.* Presentation Utility. Yusaku Hashimoto [50]announced the release of [51]tkhs-0.1.*, a simple presentation utility. If you are thinking PowerPoint is overkill for your presentation, Tkhs may fit the purpose. RFC: Unicode support in Alex. Jean-Philippe Bernardy [52]requested feedback on his modifications to the [53]Alex lexer generator to support Unicode. The prototype is [54]available on github. The Monad.Reader - Issue 14. Wouter Swierstra [55]announced Issue 14 of [56]The Monad.Reader. This issue contains three articles "Fun with Morse Code" by Heinrich Apfelmus, "Hieroglyph 2: Purely Functional Information Graphics Revisited" by Jefferson Heard, and "Lloyd Allison's Corecursive Queues: Why Continuations Matter" by Leon P Smith. TBC: Testing By Convention. Peter Gammie [57]announced the release of [58]TBC, a test harness which has features complementary to existing harnesses: it attempts to compile and run all tests, even if some do not compile or run; and tests following conventions require a lot less boilerplate. Elerea version 1.x.x. Patai Gergely [59]announced an update of his FRP library, [60]Elerea, along with some updates to the accompanying [61]example programs. The interface was changed into a monadic-applicative hybrid that distinguishes stateful and stateless combinators for safety reasons: most importantly, the latcher was removed due to various practical issues, and it is replaced by much better behaved stateless higher-order constructs. The library is now capable of handling arbitrary higher-order signals. haskell-src-exts-1.1.0. Niklas Broberg [62]announced the release of [63]haskell-src-exts-1.1.0, bringing you tuple sections, comments, and a few bug fixes. graphviz-2999.1.0.2. Ivan Lazar Miljenovic [64]announced a bug fix release of the [65]graphviz package, which fixes a bug spotted by Srihari Ramanathan where the Dot representation of Color values were double-quoted when they shouldn't have been. Leksah 0.6. Hamish Mackenzie [66]announced the 0.6 release of [67]Leksah, a Haskell IDE. New features include integrated GHCi based debugging, multi-window support, improved layout control, regular expression find and replace, ability to grep files in the current package, and improved Mac OS X integration. Semantic Web. Vasili I. Galchin [68]announced the [69]cabalisation of [70]Swish-0.2.1 (Semantic Web Inference uSing Haskell), a semantic web toolkit designed and implemented by Graham Klyne. The package now builds on GHC 6.8.2, with more improvements planned. graphviz-2999.1.0.1. Ivan Lazar Miljenovic [71]announced a bug-fix release to fix the problems with Either-based Attributes in the previous release (2999.0.0.0), spotted mainly by Zsolt Dollenstein. cautious-file 0.1.1: Ways to write a file cautiously, to avoid data loss. Robin Green [72]announced the first public release of [73]cautious-file, which provides a writeFile function that has several advantages over Prelude.writeFile: it uses the recommended way of writing a file on POSIX, so as not to expose the user to the risk of data loss after a crash or power failure; and it uses a temporary, randomly-named file for writing and only overwrites an existing file once the write is complete. Google Summer of Code Progress updates from participants in the 2008 [74]Google Summer of Code. Haddock improvements! Isaac Dupree has [75]cleaned up most of the loose edges on cross-package documentation, and has [76]begun moving comment parsing from GHC to Haddock. EclipseFP. Thomas Ten Cate is [77]finally happy with his refactorings of the Scion client, and has done [78]quite a bit of cleanup of compilation warnings and unit tests. Improving the Haskell space profiling experience. Gergely Patai posted about [79]segfaults with gtk2hs, and using Cairo instead of OpenGL for rendering, and has some [80]nice screenshots of the profiling client. haskell-src-exts -> haskell-src. Niklas Broberg has [81]started working on comment support. Fast darcs. Petr Rockai has made [82]much [83]progress, released [84]darcs 2.3.0, and posted a [85]discussion on patch formats. Discussion Adding binary to the Haskell Platform. Don Stewart began a [86]discussion thread on the possibility of adding the [87]binary package to the [88]Haskell Platform. Thinking about what's missing in our library coverage. Don Stewart [89]asked how to identify packages that ought to be added to the [90]Haskell Platform, and areas of functionality that are missing. Proposal: TypeDirectedNameResolution. Johannes Waldmann began a [91]discussion on a proposed language extension, [92]type-directed name resolution. Implicit concatenation in list comprehensions. Max Bolingbroke started a [93]discussion on a proposed syntax extension to allow multiple expressions on the left-hand side of a list comprehension, resulting in implicit concatenation. Jobs Postdoc and Ph.D. position on 3gERP-project at DIKU. Fritz Henglein [94]announced the availability of a postdoc position and a Ph.D. scholarship at the Department of Computer Science, University of Copenhagen (DIKU) within 3d generation enterprise resource planning systems (3gERP), a collaborative strategic research project with partners at DIKU (computer science), Copenhagen Business School (CBS, information systems) and Microsoft Development Center Copenhagen (MDCC, enterprise systems). Blog noise [95]Haskell news from the [96]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * >>> Joel Ray King: [97]Starting out with Haskell. * JP Moresmau: [98]Yoohoo: mazes of monad is kind of popular!. * Don Stewart (dons): [99]Haskell Package Popularity Rankings : August 2009. * David Amos: [100]Where we've been, and where we're going. * >>> Michael Feathers: [101]Functional Refactoring and "You Can't Get There From Here". * Magnus Therning: [102]Updating GHC on Arch. * Tom Schrijvers: [103]Monadic Constraint Programming with Gecode. * Luke Plant: [104]Haskell string support. * Don Stewart (dons): [105]The Haskell Platform 2009.2.0.2. * Gergely Patai: [106]More profiling goodies. * Don Stewart (dons): [107]Heuristics for Blessing Software Packages. * David Amos: [108]How to count the number of positions of Rubik's cube. * Edward Kmett: [109]Slides from Hac Phi: "All About Monoids". * Brent Yorgey: [110]Primitive species and species operations, part II. * Magnus Therning: [111]Making a choice from a list in Haskell, Vty (part 4). * Brent Yorgey: [112]Primitive species and species operations. * Thomas ten Cate: [113]The Green Bar. * Petr Rockai: [114]soc progress 10. * Brent Yorgey: [115]Hac phi roundup. * Brent Yorgey: [116]More from Hac phi. * Roman Cheplyaka: [117]CCC #5: Trial. * Eric Kow: [118]some ideas for practical QuickCheck. * Nathan Sanders: [119]Profiling in Haskell, part 2. * >>> Bj?rn Winckler: [120]Inverse functions in Haskell. * >>> Alex Handy: [121]Everyone's talking about Haskell. * Niklas Broberg: [122]Starting on the comment support . * Gergely Patai: [123]Pango font rendering on an OpenGL canvas . * Brent Yorgey: [124]Hac phi day 2. * Petr Rockai: [125]Patch Formats. * Brent Yorgey: [126]Introducing Math.Combinatorics.Species!. * Magnus Therning: [127]Making a choice from a list in Haskell, Vty (part 3). * Michael Snoyman: [128]Embedding files in a binary. * Darcs: [129]darcs 2.3.0 is released!. * Petr Rockai: [130]Darcs 2.3.0. * >>> Ionu?: [131]Haskell's prefix and infix notations. * >>> Ionu?: [132]The minus operator in Haskell. * >>> Ken Jenkins: [133]Learning Haskell (Part 2). * James Iry: [134]Void vs Unit. * Justin Grant: [135]Generating pi in Haskell. * Petr Rockai: [136]soc progress 9. * >>> Ken Jenkins: [137]Learning Haskell (Part 1). * Isaac Dupree: [138]Next Project, Move doc-parsing to from GHC to Haddock. * Roman Cheplyaka: [139]Schr??dinger's cat. * Magnus Therning: [140]Ping server in Haskell (not that kind of ping, and rather silly). * >>> hydo: [141]Haskell and Hack fanboyism.. * Chris Smith: [142]Calculating Multiplicative Inverses in Modular Arithmetic. * David Amos: [143]Faster graph symmetries using distance partitions. * Isaac Dupree: [144]more cross-package docs details. * Nick Cameron: [145]ECOOP Day 3 - Day 1 of the main conference . * Ryan Lothian: [146]Haskell Graph Plotter - Part 1. * >>> Matias Giovannini: [147]Monadic Golf. * >>> Stephan Mann: [148]Cool Haskell Function. * >>> n0ne: [149]How do you use Haskell at work?. * Adam Blinkinsop: [150]Mastermind Solver in Haskell. * Ivan Uemlianin: [151]decorate-sort-undecorate in Haskell -- Advanced!. * Don Stewart: [152]Interview for SDTimes: "Everyone's talking about Haskell". * Don Stewart: [153]Haskell Platform Progress Report. * David Amos: [154]Strong generating sets for graph symmetries. * Chris Smith: [155]The Magic of Type Classes. * Twan van Laarhoven: [156]CPS based functional references . * Thomas ten Cate: [157]More robust Scion client code. * Paul Butler: [158]N-Queens in a Tweet. Quotes of the Week * dons: i heard there were webservers written in languages other than haskell * yrlnry2: #haskell is the most functional channel I've ever seen. * JonFairbairn: And one of the tests failed because Bolivia is now the Plurinational State of Bolivia, so I've add a patch for that. I've seen politics get in the way of programming, but I've never had a bug caused by /international/ politics before. * Adamant: ah, monads. the pons asinorum of Haskell. * QP: i drink i'm two thunk for this... i'm seeing (Double, Double) * benmachine: wait why am I giving advice I don't know anything * jfredett: @yow ! YOW! I seem to SEE a SHAPR asking for FUNNY ZIPPY QUOTES, TOO bad I left them in my OTHER PANTS * Berengal: Anyone doubting the immutable value philosophy needs to try vacuum * badsheepy: [in response to a spammer] my word, i feel immediately compelled to medicate myself. * monochrom: Haskell has solved programming. All that can be said programming is already said in tutorials and the haskell wiki. That is why we drift to meta topics. * kalven: i thought there were like 10 haskell jobs in the world, all in the "let's replace excel sheets with something else" industry there are at least 20. * BMeph: okmij.net, conal.net, comonad.reader, and sigfpe.blogspot.com; the four horsemen of the Haskell Apocalypse. * jaredj: [on parsec] i thought i got it but i need to 'try' again * gwern: *ponders Haskell nerdcore: 'I'm all about exact math, yo; I eat CReal for breakfast'* * Baughn: remember that comments take up space in compiled Haskell programs, and furthermore they take up processing time if execution passes through them. For these reasons, keep comments to a minimum, and never put comments inside of optimized Haskell code. Ideally all of your comments will lie outside of the path of execution. * gbacon: okay, I just tried to type Monday, but it came out Monady. Assimilation complete. * BenLippmeier: Are Haskell and OCaml destined to be The Velvet Underground of programming languages, where hardly anyone has heard them, but everyone who does forms a band? About the Haskell Weekly News New editions are posted to [159]the Haskell mailing list as well as to [160]the Haskell Sequence and [161]Planet Haskell. [162]RSS is also available, and headlines appear on [163]haskell.org. To help create new editions of this newsletter, please see the information on [164]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [165]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://byorgey.wordpress.com/2009/07/29/hac-phi-roundup/ 3. http://news.gmane.org/gmane.comp.lang.haskell.prime 4. http://article.gmane.org/gmane.comp.lang.haskell.libraries/11611 5. http://hackage.haskell.org/package/bindings-posix 6. http://hackage.haskell.org/package/bindings%2Dcommon 7. http://hackage.haskell.org/package/bindings%2Dcommon 8. http://article.gmane.org/gmane.comp.lang.haskell.libraries/11610 9. http://hackage.haskell.org/package/bindings%2Dcommon 10. http://article.gmane.org/gmane.comp.lang.haskell.general/17425 11. http://hackage.haskell.org/package/dyre 12. http://article.gmane.org/gmane.comp.lang.haskell.general/17407 13. http://hackage.haskell.org/package/nntp 14. http://article.gmane.org/gmane.comp.lang.haskell.general/17406 15. http://hackage.haskell.org/package/GLUT 16. http://article.gmane.org/gmane.comp.lang.haskell.general/17405 17. http://hackage.haskell.org/package/OpenGL 18. http://hackage.haskell.org/package/OpenGLRaw 19. http://hackage.haskell.org/package/GLURaw 20. http://article.gmane.org/gmane.comp.lang.haskell.general/17397 21. http://hackage.haskell.org/package/yices 22. http://yices.csl.sri.com/ 23. http://article.gmane.org/gmane.comp.lang.haskell.general/17395 24. http://hackage.haskell.org/package/StateVar 25. http://hackage.haskell.org/package/OpenGL 26. http://article.gmane.org/gmane.comp.lang.haskell.general/17394 27. http://hackage.haskell.org/package/OpenAL 28. http://hackage.haskell.org/package/StateVar 29. http://hackage.haskell.org/package/ObjectName 30. http://hackage.haskell.org/package/Tensor 31. http://hackage.haskell.org/package/OpenGL 32. http://article.gmane.org/gmane.comp.lang.haskell.general/17393 33. http://hackage.haskell.org/package/Tensor 34. http://article.gmane.org/gmane.comp.lang.haskell.general/17391 35. http://darcs.net/ 36. http://article.gmane.org/gmane.comp.lang.haskell.general/17388 37. http://hackage.haskell.org/package/uacpid 38. http://article.gmane.org/gmane.comp.lang.haskell.general/17386 39. http://hackage.haskell.org/package/uacpid 40. http://article.gmane.org/gmane.comp.lang.haskell.general/17384 41. http://tabi.googlecode.com/ 42. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61980 43. http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/HTMLs/ 44. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61915 45. http://hackage.haskell.org/package/yst 46. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61874 47. http://hackage.haskell.org/platform/ 48. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61849 49. http://hackage.haskell.org/package/atom 50. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61845 51. http://hackage.haskell.org/package/tkhs 52. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61809 53. http://hackage.haskell.org/package/alex 54. git://github.com/jyp/Alex.git 55. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61800 56. http://themonadreader.wordpress.com/ 57. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61707 58. http://hackage.haskell.org/package/TBC 59. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61706 60. http://hackage.haskell.org/package/elerea 61. http://hackage.haskell.org/package/elerea-examples 62. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61703 63. http://hackage.haskell.org/package/haskell%2Dsrc%2Dexts 64. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61690 65. http://hackage.haskell.org/package/graphviz 66. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61663 67. http://leksah.org/ 68. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61613 69. http://hackage.haskell.org/package/swish 70. http://www.ninebynine.org/Software/swish-0.2.1.html 71. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61545 72. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61523 73. http://hackage.haskell.org/package/cautious-file 74. http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2008 75. http://haddock2009.wordpress.com/2009/07/20/more-cross-package-docs-details/ 76. http://haddock2009.wordpress.com/2009/07/21/next-project-move-doc-parsing-to-from-ghc-to-haddock/ 77. http://eclipsefp.wordpress.com/2009/07/19/more-robust-scion-client-code/ 78. http://eclipsefp.wordpress.com/2009/07/30/the-green-bar/ 79. http://just-bottom.blogspot.com/2009/07/using-pango-fonts-on-opengl-canvas.html 80. http://just-bottom.blogspot.com/2009/08/more-profiling-goodies.html 81. http://nibrofun.blogspot.com/2009/07/starting-on-comment-support.html 82. http://web.mornfall.net/blog/soc_progress_9.html 83. http://web.mornfall.net/blog/soc_progress_10.html 84. http://web.mornfall.net/blog/darcs_2.3.0.html 85. http://web.mornfall.net/blog/patch_formats.html 86. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/11658 87. http://hackage.haskell.org/package/binary 88. http://www.haskell.org/haskellwiki/Haskell_Platform 89. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/11625 90. http://www.haskell.org/haskellwiki/Haskell_Platform 91. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61723 92. http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution 93. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61514 94. http://article.gmane.org/gmane.comp.lang.haskell.general/17431 95. http://planet.haskell.org/ 96. http://haskell.org/haskellwiki/Blog_articles 97. http://joelrayking.wordpress.com/2009/08/08/starting-out-with-haskell/ 98. http://jpmoresmau.blogspot.com/2009/08/yoohoo-mazes-of-monad-is-kind-of.html 99. http://donsbot.wordpress.com/2009/08/06/haskell-package-popularity-rankings-august-2009/ 100. http://haskellformaths.blogspot.com/2009/08/where-weve-been-and-where-were-going.html 101. http://blog.objectmentor.com/articles/2009/08/05/functional-refactoring-and-you-cant-get-there-from-here 102. http://therning.org/magnus/archives/713 103. http://tomschrijvers.blogspot.com/2009/08/monadic-constraint-programming-with.html 104. http://lukeplant.me.uk/blog.php?id=1107301701 105. http://donsbot.wordpress.com/2009/08/03/the-haskell-platform-2009-2-0-2/ 106. http://just-bottom.blogspot.com/2009/08/more-profiling-goodies.html 107. http://donsbot.wordpress.com/2009/08/01/heuristics-for-blessing-software-packages/ 108. http://haskellformaths.blogspot.com/2009/08/how-to-count-number-of-positions-of.html 109. http://comonad.com/reader/2009/hac-phi-slides/ 110. http://byorgey.wordpress.com/2009/07/31/primitive-species-and-species-operations-part-ii/ 111. http://therning.org/magnus/archives/710 112. http://byorgey.wordpress.com/2009/07/30/primitive-species-and-species-operations/ 113. http://eclipsefp.wordpress.com/2009/07/30/the-green-bar/ 114. http://web.mornfall.net/blog/soc_progress_10.html 115. http://byorgey.wordpress.com/2009/07/29/hac-phi-roundup/ 116. http://byorgey.wordpress.com/2009/07/25/more-from-hac-%cf%86/ 117. http://ro-che.blogspot.com/2009/07/ccc-5.html 118. http://koweycode.blogspot.com/2009/07/some-ideas-for-practical-quickcheck.html 119. http://sandersn.com/blog/index.php?title=profiling_in_haskell_part_2 120. http://b4winckler.wordpress.com/2009/07/28/inverse-functions-in-haskell/ 121. http://www.sdtimes.com/blog/post/2009/07/27/Everyonee28099s-talking-about-Haskell.aspx 122. http://nibrofun.blogspot.com/2009/07/starting-on-comment-support.html 123. http://just-bottom.blogspot.com/2009/07/using-pango-fonts-on-opengl-canvas.html 124. http://byorgey.wordpress.com/2009/07/25/hac-%cf%86-day-2/ 125. http://web.mornfall.net/blog/patch_formats.html 126. http://byorgey.wordpress.com/2009/07/24/introducing-math-combinatorics-species/ 127. http://therning.org/magnus/archives/702 128. http://blog.snoyman.com/2009/07/23/embedding-files-in-a-binary/ 129. http://blog.darcs.net/2009/07/darcs-230-is-released.html 130. http://web.mornfall.net/blog/darcs_2.3.0.html 131. http://learninghaskell.wordpress.com/2009/07/23/haskell-prefix-and-infix-notations-for-functions/ 132. http://learninghaskell.wordpress.com/2009/07/23/the-minus-operator-in-haskell/ 133. http://webscript.princeton.edu/~kjenkins/wordpress/2009/07/learning-haskell-part-2/ 134. http://james-iry.blogspot.com/2009/07/void-vs-unit.html 135. http://jng.imagine27.com/articles/2009-07-23-094212_generating_pi_in_haskell.html 136. http://web.mornfall.net/blog/soc_progress_9.html 137. http://webscript.princeton.edu/~kjenkins/wordpress/2009/07/learning-haskell/ 138. http://haddock2009.wordpress.com/2009/07/21/next-project-move-doc-parsing-to-from-ghc-to-haddock/ 139. http://ro-che.blogspot.com/2009/07/schrodingers-cat.html 140. http://therning.org/magnus/archives/698 141. http://www.l2mlogistics.com/2009/07/haskell-and-hack-fanboyism.html 142. http://cdsmith.wordpress.com/2009/07/20/calculating-multiplicative-inverses-in-modular-arithmetic/ 143. http://haskellformaths.blogspot.com/2009/07/faster-graph-symmetries-using-distance.html 144. http://haddock2009.wordpress.com/2009/07/20/more-cross-package-docs-details/ 145. http://featherweightmusings.blogspot.com/2009/07/ecoop-day-3-day-1-of-main-conference.html 146. http://www.ryanlothian.com/articles/haskell-graphplotter 147. http://alaska-kamtchatka.blogspot.com/2009/07/monadic-golf.html 148. http://stephenmann.net/2009/07/17/cool-haskell-function/ 149. http://actuarialprog.wordpress.com/2009/07/13/how-do-you-use-haskell-at-work/ 150. http://adam.blinkinblogs.net/mastermind-solver-in-haskell 151. http://llaisdy.wordpress.com/2009/07/11/decorate-sort-undecorate-in-haskell-advanced/ 152. http://donsbot.wordpress.com/2009/07/27/interview-for-sdtimes-everyone%e2%80%99s-talking-about-haskell/ 153. http://donsbot.wordpress.com/2009/07/26/haskell-platform-progress-report/ 154. http://haskellformaths.blogspot.com/2009/07/strong-generating-sets-for-graph.html 155. http://cdsmith.wordpress.com/2009/07/23/the-magic-of-type-classes/ 156. http://twan.home.fmf.nl/blog/haskell/cps-functional-references.details 157. http://eclipsefp.wordpress.com/2009/07/19/more-robust-scion-client-code/ 158. http://paulbutler.org/archives/n-queens-in-a-tweet/ 159. http://www.haskell.org/mailman/listinfo/haskell 160. http://sequence.complete.org/ 161. http://planet.haskell.org/ 162. http://sequence.complete.org/node/feed 163. http://haskell.org/ 164. http://haskell.org/haskellwiki/HWN 165. http://code.haskell.org/~byorgey/code/hwn/ From ddssff at gmail.com Sat Aug 8 19:05:39 2009 From: ddssff at gmail.com (David Fox) Date: Sat Aug 8 18:46:15 2009 Subject: [Haskell] Data.Generics.gzip3 anyone? In-Reply-To: References: Message-ID: Ok, here is another piece of the three way merging puzzle. The gzip3 function can do three way merging when there are no conflicts that need to be resolved manually. When there are such conflicts we need a user interface which displays the common ancestor, the two alternative edits, and provides a place to input the merged result. For this we are using a generic programming interface to formlets . Formlets are members of class Applicative, so we can write a function to turn a value into a formlet using a gmapA function (this is syb-with-class generics): type GenericA f ctx = forall a. (Applicative f, Data ctx a) => a -> f a gmapA :: (Applicative f) => Proxy ctx -> GenericA f ctx -> GenericA f ctx gmapA ctx f = gfoldl ctx k pure where k c x = c <*> (f x) Then the formlet for a value is created using something like this: gmapA formletOfProxy (formletOfD dict) x For three way merging, though, we need to turn three values of the same type into a formlet, something like a gmap3A function: gmap3A formletOfProxy (formletOfD dict) ancestor variant1 variant2 Its this gmap3A function that I'm unable to create. I'm hoping someone out there will find this a piece of cake... On Mon, Jun 1, 2009 at 3:40 PM, Ralf Laemmel wrote: > > Thank you! What I have in mind is three way merging - you have two > > revisions based on the same original value, and you need to decide > whether > > they can be merged automatically or they need to be merged by a user. > You > > only have a real conflict when both revisions differ from the original > and > > from each other. > > Here is the completed exercise. > For comparison, the two args versions are shown up-front. > There is gzipWithM3 needed for gzip3, and gzip3 itself. > I also made it so that the top-level gzip functions have the > appropriate polymorphism. > Say same type for the args rather than independent polymorphism. > > {-# LANGUAGE RankNTypes #-} > > import Prelude hiding (GT) > import Data.Generics > > -- As originally defined: Twin map for transformation > > gzipWithT2 :: GenericQ (GenericT) -> GenericQ (GenericT) > gzipWithT2 f x y = case gmapAccumT perkid funs y of > ([], c) -> c > _ -> error "gzipWithT2" > where > perkid a d = (tail a, unGT (head a) d) > funs = gmapQ (\k -> GT (f k)) x > > > -- As originally defined: Twin map for transformation > > gzipWithM2 :: Monad m => GenericQ (GenericM m) -> GenericQ (GenericM m) > gzipWithM2 f x y = case gmapAccumM perkid funs y of > ([], c) -> c > _ -> error "gzipWithM" > where > perkid a d = (tail a, unGM (head a) d) > funs = gmapQ (\k -> GM (f k)) x > > > -- As originally defined: generic zip > > gzip2 :: > (forall x. Data x => x -> x -> Maybe x) > -> (forall x. Data x => x -> x -> Maybe x) > > gzip2 f = gzip2' f' > where > f' :: GenericQ (GenericM Maybe) > f' x y = cast x >>= \x' -> f x' y > gzip2' :: GenericQ (GenericM Maybe) -> GenericQ (GenericM Maybe) > gzip2' f x y = > f x y > `orElse` > if toConstr x == toConstr y > then gzipWithM2 (gzip2' f) x y > else Nothing > > > -- For three args now > > gzipWithT3 :: > GenericQ (GenericQ (GenericT)) > -> GenericQ (GenericQ (GenericT)) > gzipWithT3 f x y z = > case gmapAccumT perkid funs z of > ([], c) -> c > _ -> error "gzipWithT3" > where > perkid a d = (tail a, unGT (head a) d) > funs = case gmapAccumQ perkid' funs' y of > ([], q) -> q > _ -> error "gzipWithT3" > where > perkid' a d = (tail a, unGQ (head a) d) > funs' = gmapQ (\k -> (GQ (\k' -> GT (f k k')))) x > > gzipWithM3 :: Monad m > => GenericQ (GenericQ (GenericM m)) > -> GenericQ (GenericQ (GenericM m)) > gzipWithM3 f x y z = > case gmapAccumM perkid funs z of > ([], c) -> c > _ -> error "gzipWithM3" > where > perkid a d = (tail a, unGM (head a) d) > funs = case gmapAccumQ perkid' funs' y of > ([], q) -> q > _ -> error "gzipWithM3" > where > perkid' a d = (tail a, unGQ (head a) d) > funs' = gmapQ (\k -> (GQ (\k' -> GM (f k k')))) x > > gzip3 :: > (forall x. Data x => x -> x -> x -> Maybe x) > -> (forall x. Data x => x -> x -> x -> Maybe x) > > gzip3 f = gzip3' f' > where > f' :: GenericQ (GenericQ (GenericM Maybe)) > f' x y z = cast x >>= \x' -> cast y >>= \y' -> f x' y' z > gzip3' :: > GenericQ (GenericQ (GenericM Maybe)) > -> GenericQ (GenericQ (GenericM Maybe)) > gzip3' f x y z = > f x y z > `orElse` > if and [toConstr x == toConstr y, toConstr y == toConstr z] > then gzipWithM3 (gzip3' f) x y z > else Nothing > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090808/d1a53ecc/attachment-0001.html From ddssff at gmail.com Sat Aug 8 19:09:11 2009 From: ddssff at gmail.com (David Fox) Date: Sat Aug 8 18:49:48 2009 Subject: [Haskell] Data.Generics.gzip3 anyone? In-Reply-To: References: Message-ID: On Sat, Aug 8, 2009 at 4:05 PM, David Fox wrote: > Ok, here is another piece of the three way merging puzzle. The gzip3 > function can do three > way merging when there are no conflicts that need to be resolved manually. > When there are > such conflicts we need a user interface which displays the common ancestor, > the two alternative > edits, and provides a place to input the merged result. For this we are > using a generic > programming interface to formlets . Formlets are members of class > Applicative, so we can write > a function to turn a value into a formlet using a gmapA function (this is > syb-with-class generics): > > type GenericA f ctx = forall a. (Applicative f, Data ctx a) => a -> f a > > gmapA :: (Applicative f) => Proxy ctx -> GenericA f ctx -> GenericA f ctx > gmapA ctx f = > gfoldl ctx k pure > where k c x = c <*> (f x) > > Then the formlet for a value is created using something like this: > > gmapA formletOfProxy (formletOfD dict) x > > For three way merging, though, we need to turn three values of the same > type into a formlet, > something like a gmap3A function: > > gmap3A formletOfProxy (formletOfD dict) ancestor variant1 variant2 I guess this should be a more like this: gmap3A formletOfProxy (formletOf3WayMergeD dict) ancestor variant1 variant2 when converting a value of an arbitrary algebraic type, and formletOf3WayMerge would have custom implementations for various primitive and more specialized types. > > Its this gmap3A function that I'm unable to create. I'm hoping someone out > there will find this > a piece of cake... > > > On Mon, Jun 1, 2009 at 3:40 PM, Ralf Laemmel wrote: > >> > Thank you! What I have in mind is three way merging - you have two >> > revisions based on the same original value, and you need to decide >> whether >> > they can be merged automatically or they need to be merged by a user. >> You >> > only have a real conflict when both revisions differ from the original >> and >> > from each other. >> >> Here is the completed exercise. >> For comparison, the two args versions are shown up-front. >> There is gzipWithM3 needed for gzip3, and gzip3 itself. >> I also made it so that the top-level gzip functions have the >> appropriate polymorphism. >> Say same type for the args rather than independent polymorphism. >> >> {-# LANGUAGE RankNTypes #-} >> >> import Prelude hiding (GT) >> import Data.Generics >> >> -- As originally defined: Twin map for transformation >> >> gzipWithT2 :: GenericQ (GenericT) -> GenericQ (GenericT) >> gzipWithT2 f x y = case gmapAccumT perkid funs y of >> ([], c) -> c >> _ -> error "gzipWithT2" >> where >> perkid a d = (tail a, unGT (head a) d) >> funs = gmapQ (\k -> GT (f k)) x >> >> >> -- As originally defined: Twin map for transformation >> >> gzipWithM2 :: Monad m => GenericQ (GenericM m) -> GenericQ (GenericM m) >> gzipWithM2 f x y = case gmapAccumM perkid funs y of >> ([], c) -> c >> _ -> error "gzipWithM" >> where >> perkid a d = (tail a, unGM (head a) d) >> funs = gmapQ (\k -> GM (f k)) x >> >> >> -- As originally defined: generic zip >> >> gzip2 :: >> (forall x. Data x => x -> x -> Maybe x) >> -> (forall x. Data x => x -> x -> Maybe x) >> >> gzip2 f = gzip2' f' >> where >> f' :: GenericQ (GenericM Maybe) >> f' x y = cast x >>= \x' -> f x' y >> gzip2' :: GenericQ (GenericM Maybe) -> GenericQ (GenericM Maybe) >> gzip2' f x y = >> f x y >> `orElse` >> if toConstr x == toConstr y >> then gzipWithM2 (gzip2' f) x y >> else Nothing >> >> >> -- For three args now >> >> gzipWithT3 :: >> GenericQ (GenericQ (GenericT)) >> -> GenericQ (GenericQ (GenericT)) >> gzipWithT3 f x y z = >> case gmapAccumT perkid funs z of >> ([], c) -> c >> _ -> error "gzipWithT3" >> where >> perkid a d = (tail a, unGT (head a) d) >> funs = case gmapAccumQ perkid' funs' y of >> ([], q) -> q >> _ -> error "gzipWithT3" >> where >> perkid' a d = (tail a, unGQ (head a) d) >> funs' = gmapQ (\k -> (GQ (\k' -> GT (f k k')))) x >> >> gzipWithM3 :: Monad m >> => GenericQ (GenericQ (GenericM m)) >> -> GenericQ (GenericQ (GenericM m)) >> gzipWithM3 f x y z = >> case gmapAccumM perkid funs z of >> ([], c) -> c >> _ -> error "gzipWithM3" >> where >> perkid a d = (tail a, unGM (head a) d) >> funs = case gmapAccumQ perkid' funs' y of >> ([], q) -> q >> _ -> error "gzipWithM3" >> where >> perkid' a d = (tail a, unGQ (head a) d) >> funs' = gmapQ (\k -> (GQ (\k' -> GM (f k k')))) x >> >> gzip3 :: >> (forall x. Data x => x -> x -> x -> Maybe x) >> -> (forall x. Data x => x -> x -> x -> Maybe x) >> >> gzip3 f = gzip3' f' >> where >> f' :: GenericQ (GenericQ (GenericM Maybe)) >> f' x y z = cast x >>= \x' -> cast y >>= \y' -> f x' y' z >> gzip3' :: >> GenericQ (GenericQ (GenericM Maybe)) >> -> GenericQ (GenericQ (GenericM Maybe)) >> gzip3' f x y z = >> f x y z >> `orElse` >> if and [toConstr x == toConstr y, toConstr y == toConstr z] >> then gzipWithM3 (gzip3' f) x y z >> else Nothing >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090808/477406c0/attachment.html From yminsky at janestcapital.com Tue Aug 11 17:52:44 2009 From: yminsky at janestcapital.com (Yaron Minsky) Date: Tue Aug 11 17:33:11 2009 Subject: [Haskell] Jane Street is Hiring (as if you didn't already know) Message-ID: <1250027564.4019.126.camel@nyc-qws-007.delacy.com> This is my periodic reminder to the FP world that Jane Street is looking to hire functional programmers. I've started getting the occasional inquiry coming in from people who are clearly unsure if our previous hiring announcements still apply, and I wanted to make it clear that they do. Also, I wanted to mention that I will be at parts of ICFP, CUFP and DEFUN this year, so if you're interested, come and talk to me there. Without further ado, and at the risk of boring longtime residents of the list to tears: Despite the problems besetting much of the financial industry, we have grown strongly in the last few years in our people, our technology, the scope of our business and its profitability. We now have over 30 OCaml developers, and we are actively looking to hire more in Tokyo, London and New York. For someone who cares about functional programming, Jane Street is an interesting place to consider. Jane Street has invested deeply in OCaml, to the point where we now have the largest team of OCaml programmers in any industrial setting, and probably the world's largest OCaml codebase--over a million lines. We really believe in functional programming, and use OCaml for everything from research to systems adminstration to trading systems. The atmosphere is informal and intellectual, with a focus on learning. The work itself is deeply challenging, and you get to see the practical impact of your efforts in quick and dramatic terms. Jane Street is also a small enough place that people have the freedom to get involved in many different areas of the business. Unlike many financial firms, software and technology are considered a core part of what we do, not some segmented-off cost center that the people who run the business don't think about. Jane Street is a place where people really care about the quality of the software, to the point that several of the most senior members of the firm, who do not have technology backgrounds, nonetheless review critical portions of the codebase before they can go into production. If you'd like to learn more, here are some links. First, there are a couple of papers we've written about our experiences here. http://www.janestreet.com/technology/articles.php We also have a technically-oriented blog: http://ocaml.janestreet.com For a (recruiting-oriented) overview of Jane Street, here's the firm website: http://janestreet.com If you're interested, send me a resume and cover letter. y From dons at galois.com Tue Aug 11 17:59:55 2009 From: dons at galois.com (Don Stewart) Date: Tue Aug 11 17:42:29 2009 Subject: [Haskell] Galois is Hiring Message-ID: <20090811215955.GK25224@whirlpool.galois.com> Galois is continuing to hire. We will also be at ICFP and related events, so come and see Lee Pike or me. We have multiple positions for talented functional programmers (with both junior and senior positions). A strong functional programming ability is an advantage (you will be programming in Haskell), and a good computer science background is required. Experience with compilers, operating systems, networking, security, and formal methods is of particular interest. Galois is based in Portland, Oregon. Our engineers work with functional languages, designing and developing advanced technologies for safety and security-critical systems, networks, and applications. Galois technical staff members play a pivotal role in developing advanced software technology. Enginners work in small team settings, and must successfully interact with clients, partners, and other employees in a highly cooperative, collaborative, and intellectually challenging environment. Technical staff may be called upon to write proposals, gather requirements, and work in all stages of the software development process, from requirements gathering to testing and validation. Additional duties may include project management, technology research and development, and technical infrastructure development. We?re looking for people who can invent, learn, think, and inspire. We reward creativity and thrive on collaboration. We offer great benefits and perks, including a 401K plan, stock options, paid vacation, family health plan, flexible work schedule, a casual work environment, snacks, espresso and foosball. A Masters or Ph.D. degree in Computer Science is desirable. Additionally, a strong programming background and experience with Haskell or other functional programming languages is preferred. You must work well with customers, including building rapport, identifying needs, and communicating with strong written, verbal and presentation skills. Must be highly motivated and able to self-manage to deadlines and quality goals. To learn more about us, visit http://www.galois.com and http://www.galois.com/company/careers The types of technology we use are covered in our blog: http://www.galois.com/blog/ We?d like to hear from you! Send your cover letter and resume to us at jobs2009 at galois.com. From cmoore at wamboli.com Tue Aug 11 19:02:32 2009 From: cmoore at wamboli.com (Clint Moore) Date: Tue Aug 11 18:43:02 2009 Subject: [Haskell] Re: [Haskell-cafe] ANNOUNCE: HacPDX, A Hackathon in Portland In-Reply-To: <4c44d90b0908111546g5950ace0yc66b6c5d088d6e57@mail.gmail.com> References: <4c44d90b0908111546g5950ace0yc66b6c5d088d6e57@mail.gmail.com> Message-ID: <157577bd0908111602x46a4edfdyc8c2bf14710daefd@mail.gmail.com> On Tue, Aug 11, 2009 at 3:46 PM, Thomas DuBuisson wrote: > HacPDX is an opportunity for Portland Haskell hackers to join together > in building and improving libraries and tools. ?If you've never been, > hackathons are typically not only a good opportunity for experienced > devs to work together but also a great way for newcomers to get > involved in the community. If anyone in the Seattle area is interested in going and doesn't have a ride, the Bonney Lake Nerd Wagon will be heading down for the event if you want to catch a ride. Get in touch with me for more info. From P.W.Trinder at hw.ac.uk Wed Aug 12 06:46:46 2009 From: P.W.Trinder at hw.ac.uk (Trinder, Philip W) Date: Wed Aug 12 06:31:23 2009 Subject: [Haskell] Parallel Symbolic Computing Research Post In-Reply-To: <976F9C1B58DCB84EA7021B8BFB483B8E0C451EA1@ex6.mail.win.hw.ac.uk> References: <976F9C1B58DCB84EA7021B8BFB483B8E0C451EA1@ex6.mail.win.hw.ac.uk> Message-ID: <976F9C1B58DCB84EA7021B8BFB483B8E0CC36DD2@ex6.mail.win.hw.ac.uk> The next generation of HPC platform will provide teraflop performance from 10^5 or more cores. A major challenge is to develop the programming models and software infrastructures to effectively exploit these architectures. In the HPC-GAP project (High Performance Computational Algebra and Discrete Mathematics EPSRC EP/G055181) we aim to address this challenge for the GAP Group Algebra package. You will join a team of four researchers in an ambitious programme to adapt the GAP computational algebra system to take advantage of modern high performance computers. You will collaborate with other HPC-GAP members at Aberdeen and St Andrews and Edinburgh Universities. You will take part in and publish research using the software you develop. You will have excellent parallel system engineering expertise, a degree in computer science, an appropriate PhD or equivalent, and good teamwork skills. Desirable criteria include functional language experience, a track record of academic publications, experience preparing research grant applications, and experience with a range of software technologies. You will start on 1 September 2009 and continue until the end of the grant in August 2013. Full details at www.jobs.ac.uk/jobs/SP072/Research_Associate_-_Parallel_Symbolic_Computi ng/ -------------------------------------------- Phil Trinder School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh, EH14 4AS E: P.W.Trinder@hw.ac.uk T: +44 (0)131 451 3435 F: +44 (0)131 451 3327 I: www.macs.hw.ac.uk/~trinder -- Heriot-Watt University is a Scottish charity registered under charity number SC000278. From ifl2009 at shu.edu Thu Aug 13 10:13:38 2009 From: ifl2009 at shu.edu (IFL 2009) Date: Thu Aug 13 09:54:09 2009 Subject: [Haskell] IFL 2009: Final Call for Papers and Participation Message-ID: An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090813/ae3c1864/attachment-0001.html From Sven.Panne at aedion.de Sun Aug 16 12:12:02 2009 From: Sven.Panne at aedion.de (Sven Panne) Date: Sun Aug 16 11:52:21 2009 Subject: [Haskell] ANNOUNCE: GLUT 2.2.1.0 Message-ID: <200908161812.02982.Sven.Panne@aedion.de> A new version of the GLUT package has been uploaded to Hackage. * The package is now autoconf-free. API entries are resolved dynamically at runtime, just like the OpenGLRaw and GLURaw packages. * Support for sRGB framebuffers has been added, just use SRGBMode with initialDisplayMode. To use this functionality, you need the upcoming freeglut 2.6.0 library, older versions and "classic" GLUT do not support this feature. * Support for context profiles has been added via initialContextProfile. Again, this works with the upcoming freeglut 2.6.0 library only. Cheers, ? ?S. From ganesh.sittampalam at credit-suisse.com Mon Aug 17 12:39:19 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Aug 17 12:19:43 2009 Subject: [Haskell] Credit Suisse is hiring Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F906@ELON17P32001A.csfb.cs-group.com> Hi, Just to chime in with the spate of job advertisements, the Global Modelling and Analytics Group (GMAG) at Credit Suisse is once again looking to hire functional programmers. The group consists of about 130 people worldwide. The majority of the group are mathematicians engaged in developing mathematical models for financial products traded by the division. Approximately 20 people are primarily computing experts, based in the Architecture and Delivery (AD) subgroup within GMAG, and successful candidates will also be based in this group. We are already making heavy use of functional programming within the group, and we expect to increase this in the future. Some information about our Haskell projects can be found here: http://www.haskell.org/communities/05-2009/html/report.html#creditsuisse ; more recently we have adopted F# for implementing and deploying models on the .NET platform and we are currently ramping up our F# usage. Our team works closely with the modellers to help them leverage functional programming to improve the design of their code. Key requirements: At least one of: - An academic track record in functional programming. - Significant experience of "real-world" computing environments, preferably using functional programming. Excellent communication skills in order to convey new ideas to our modelling team. Location: London or New York Contact: Howard Mansell Myself (Ganesh Sittampalam ) and Tobias Gedell will be attending ICFP 2009 and associated workshops in Edinburgh - if you'd like to discuss this in person, get in touch with us by email, or just grab one of us there. Background information: As one of the world's leading banks, Credit Suisse provides its clients with investment banking, private banking and asset management services worldwide. Founded in 1856, Credit Suisse has a long tradition of meeting the complex financial needs of a wide range of clients, offering advisory services, comprehensive solutions and innovative products to companies, institutional clients and high-net-worth private clients globally. Credit Suisse is active in over 50 countries and employs approximately 46,000 people. Further information can be found at www.credit-suisse.com. Cultural diversity is essential to our success. As such, we employ people from more than 100 countries. Credit Suisse empowers employees to work openly and respectfully with each other and with clients, ultimately striving to deliver superior results while offering initiatives and programs to assist employees achieve a healthy work-life balance. The Global Modelling and Analytics Group (GMAG) is responsible for producing state-of-the-art pricing, trading and risk management models for Credit Suisse. These models are used across a range of businesses in the Fixed Income and Equity departments. The group performs the full spectrum of quantitative work, from mathematical modelling through software implementation and delivery, to risk analysis of trades and existing portfolios. The group's mandate covers all major asset classes, including Credit Derivatives, Commodities, Emerging Markets, Equity Derivatives and Convertibles, Exotics, Foreign Exchange, Fund Linked Products, Interest Rate Products and Mortgage Derivatives. GMAG operates globally with members located in London, New York, Hong Kong, Tokyo, Zurich and S?o Paolo. Established in 1990, GMAG stands out as a unified quant group that has been covering all major product areas since its inception. The group has always enjoyed a strong relationship with Trading, Structuring and Sales, assisting them with trade pricing and risk management. As the group is based on the trading floor, it is ideally placed to respond to the financial modelling needs of the businesses it supports. The breadth of GMAG's mandate makes it uniquely positioned to leverage the skills and experience of its members, and to provide a consistent modelling approach across all areas. Over time, the group has developed an extensive suite of pricing models on a common platform with complete integration across all asset classes. Quantitative Analysts in GMAG carry out a range of activities which include the creation of sophisticated mathematical models for the valuation of complex derivatives, development of the technology platform used to deliver models and driving the use of these models throughout the bank. Our Quantitative Analysts typically hold an advanced quantitative degree, have excellent analytical and problem-solving skills, demonstrate creative thinking, have strong programming skills, and are confident communicators. =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090817/d54c2ff8/attachment.html From niklas.broberg at gmail.com Sat Aug 22 16:26:46 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Aug 22 16:06:47 2009 Subject: [Haskell] ANN: haskell-src-exts-1.1.3 Message-ID: Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.1.3. * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via darcs: darcs get http://code.haskell.org/haskell-src-exts * Report bugs: http://trac.haskell.org/haskell-src-exts haskell-src-exts is a package for Haskell source code manipulation. In particular it defines an abstract syntax tree representation, and a parser and pretty-printer to convert between this representation and String. It handles (almost) all syntactic extensions to the Haskell 98 standard implemented by GHC, and the parsing can be parametrised on what extensions to recognise. haskell-src-exts-1.1.3 is a highly experimental release, which (apart from a small bug fix, see below) doesn't do anything at all to the current stable part of haskell-src-exts. But the release is far from as boring as all that may sound, as it includes a whole new set of modules implementing a new and more accurate syntax tree where all nodes are adorned with annotations. Together with this comes a parser that retains exact source information, stored in the aforementioned annotations. There is also support for various precision for source information, including SrcSpans. The new modules mirror the ones in the stable part of haskell-src-exts but instead live in Language.Haskell.Exts.Annotated{.Syntax,.Parser,...} (except that SrcLoc and friends now have their own module). The point of this release is that those of you that for one reason or other are waiting for these features can help me look, feel, test and comment these things in isolation, and hopefully report a lot of bugs, before I integrate this stuff with the main haskell-src-exts body of code. Note that that coming integration is intended to be backwards-compatible, but a lot of the behind-the-scenes will be switched over to the new and more general machinery. Feature-wise, with this accurate source tree in hand, the next step is to write a printer that uses the full location information to allow full and exact round-tripping, i.e. (print . parse == id). == haskell-src-exts-1.1.3 == * Adds support for more accurate, and fully annotated, abstract syntax, see above. * Fixes a bug that forced 'rec' statement groups to end with a qualifier (like 'do'). Cheers and Happy Haskelling, /Niklas From jeremy at n-heptane.com Sat Aug 22 16:34:56 2009 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Sat Aug 22 16:14:55 2009 Subject: [Haskell] Re: [Haskell-cafe] ANN: haskell-src-exts-1.1.3 In-Reply-To: References: Message-ID: <87iqgfzixb.wl%jeremy@n-heptane.com> Nice! Does this mean that in the near future trhsx won't strip out all the haddock comments? That would be great. - jeremy From niklas.broberg at gmail.com Sun Aug 23 05:47:28 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Aug 23 05:27:23 2009 Subject: [Haskell] Re: [Haskell-cafe] ANN: haskell-src-exts-1.1.3 In-Reply-To: <87iqgfzixb.wl%jeremy@n-heptane.com> References: <87iqgfzixb.wl%jeremy@n-heptane.com> Message-ID: Oops, please consider this the announcement of the release of haskell-src-exts-1.1.3.1, since I stupidly forgot to add the new SrcLoc module to the list of exposed modules in cabal (why doesn't cabal warn about that? *grumble*). So those of you who already tried 1.1.3 it will have noticed that it failed to compile, sorry about that! On Sat, Aug 22, 2009 at 10:34 PM, Jeremy Shaw wrote: > Does this mean that in the near future trhsx won't strip out all the > haddock comments? That would be great. I can't promise about the *near* future, there's that little matter of time, but it's definitely the plan to turn trhsx over to the new cool machinery at some point, which will indeed allow it to retain all comments. :-) Cheers, /Niklas From gwern0 at gmail.com Sun Aug 23 06:01:58 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Aug 23 05:41:57 2009 Subject: [Haskell] Re: [Haskell-cafe] ANN: haskell-src-exts-1.1.3 In-Reply-To: References: <87iqgfzixb.wl%jeremy@n-heptane.com> Message-ID: On Sun, Aug 23, 2009 at 5:47 AM, Niklas Broberg wrote: > Oops, please consider this the announcement of the release of > haskell-src-exts-1.1.3.1, since I stupidly forgot to add the new > SrcLoc module to the list of exposed modules in cabal (why doesn't > cabal warn about that? *grumble*). http://hackage.haskell.org/trac/hackage/ticket/274 -- gwern From dsouza at bitforest.org Mon Aug 24 07:48:14 2009 From: dsouza at bitforest.org (Diego Souza) Date: Mon Aug 24 07:31:45 2009 Subject: [Haskell] ANNOUNCE: OAuth library in haskell Message-ID: <20090824114814.GC3400@mephisto.bitforest.org> Dear Haskellers, hoauth is a library which helps you to deal with oauth protocol. Currently it supports only consumer side applications, but there are plans to add service providers support in near future. The source code can be found at [darcs]: http://projects.bitforest.org/hoauth/ and now in hackage: http://hackage.haskell.org/package/hoauth If you have any questions, comments or criticism, please get in touch with me. I'll appreciate it very much, specially because there are so many things yet to learn. Thanks, PS: This is the first piece of code I produce in Haskell since I've start learning it few months ago. I must say it has been a joy since then. -- ~dsouza yahoo!im: paravinicius gpg key fingerprint: 71B8 CE21 3A6E F894 5B1B 9ECE F88E 067F E891 651E From explicitcall at googlemail.com Mon Aug 24 08:49:20 2009 From: explicitcall at googlemail.com (Max Desyatov) Date: Mon Aug 24 08:29:11 2009 Subject: [Haskell] ANNOUNCE: graphtype =?utf-8?b?4oCU?= A simple tool to illustrate dependencies between Haskell types Message-ID: <87y6p9v0kv.fsf@zagan.made.you> While developing applications which deal with complex data it is crucial to know how exactly you manipulate this data. Haskell provides excellent tools for expressing a data scheme you work with: ADTs, `type` and `newtype` declarations, type classes and much more is hidden in rich Haskell's type system. Obviously, when types of data in your domain you work with grow ? all declarations grow, and it becomes hard to grasp all dependencies, to change them and to remove them deliberately. graphtype was developed to visualise type declarations in you Haskell source files. It produces .dot-file for subsequent processing with graphviz. Results for example file bundled with graphtype: http://i.piccy.info/i4/00/90/bfa07290012c2d3b455696bdaa86.png To play with it, you can use hackage: http://hackage.haskell.org/package/graphtype or hack some code: http://github.com/explicitcall/graphtype Visualisation of dependencies in complex type class hierarchies is still on the way. It isn't obvious how do to this nicely, as in most cases type class declarations are imported from other libraries, and you don't always have source files for them. Anyway, graphtype is fairly usable. Leave here your questions, suggestions and have fun looking at type dependencies in your code. WBR, Max From simon at joyful.com Mon Aug 24 15:28:38 2009 From: simon at joyful.com (Simon Michael) Date: Mon Aug 24 15:08:34 2009 Subject: [Haskell] ANN: rss2irc 0.3 released Message-ID: <8C9FDF81-21FD-42DA-A42C-ED9EC1A76E3F@joyful.com> rss2irc is an irc bot created by Don Stewart to watch rss feeds and announce new items on irc. I have been tweaking and testing it for a while, and have taken up the maintainer reins. I'm happy to announce release 0.3, with: - reliable http networking - irc flood protection - better error handling & reporting - extensive debugging output - Atom support - more useful defaults (enter channel silently, hide email addresses etc.) - precise control of irc output, including regexp rewrites - installable on mac osx Feedback and patches welcome. I am currently using it to run a number of announce-bots on freenode, including hackagebot and darcscommitbot. (A tip: if you experiment, avoid joining the irc server too frequently; once per minute may be ok.) home: http://hackage.haskell.org/package/rss2irc darcs repo: http://joyful.com/darcsweb/darcsweb.cgi?r=rss2irc -Simon From john at repetae.net Tue Aug 25 00:13:36 2009 From: john at repetae.net (John Meacham) Date: Mon Aug 24 23:53:29 2009 Subject: [Haskell] ANNOUNCE: jhc 0.7.1 Message-ID: <20090825041336.GI18852@sliver.repetae.net> Hi, I am happy to announce the jhc optimizing haskell compiler version 0.7.1. Information on installing jhc is here: http://repetae.net/computer/jhc/building.shtml And the Main page is here: http://repetae.net/computer/jhc There have been a lot of changes since the last public release, Some notable ones are: * The use of a general compiler cache by default rather than object files. This means work done by jhc is shared between projects, jhc uses cryptographic hashes internally to never compile the same piece of code more than once. This has numerous benefits, a notable one being speed. * Reworked library support. Jhc libraries are now much more general, when linking only the bits needed are loaded from the hl file, libraries are allowed to re-export modules from other libraries, making versioning or providing multiple interfaces to the same functionality a lot simpler. Library conflicts are 'lazy', like ambiguity errors now. * Updated Manual, clearer build instructions * Support for writing pure C libraries in Haskell. * numerous library updates, filled out many IO routines that were stubs before * Smart progress meters when compiler for a better user experience * performs all typechecking before compilation, for a faster edit-compile loop when writing code with jhc. * various bug fixes * Cross Compilation improvements, for instance you can compile for windows transparently on a linux box. Or for an embedded target that is independent of the host. * Better Mac OSX Support, as both a host and target. If you are wondering about the large version number bump since the last release, It is because several versions were released only internally to the jhc list for testing. If you are interested in jhc, join the list at: http://www.haskell.org/mailman/listinfo/jhc John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From tanimoto at arizona.edu Tue Aug 25 00:39:10 2009 From: tanimoto at arizona.edu (Paulo Tanimoto) Date: Tue Aug 25 00:19:21 2009 Subject: [Haskell] Re: [Haskell-cafe] ANNOUNCE: jhc 0.7.1 In-Reply-To: <20090825041336.GI18852@sliver.repetae.net> References: <20090825041336.GI18852@sliver.repetae.net> Message-ID: Hi John, On Mon, Aug 24, 2009 at 11:13 PM, John Meacham wrote: > Hi, I am happy to announce the jhc optimizing haskell compiler version 0.7.1. > > Information on installing jhc is here: http://repetae.net/computer/jhc/building.shtml > And the Main page is here: ?http://repetae.net/computer/jhc > Cheers! Thanks for the great work. It took me 5 minutes between downloading the tarball and compiling "hello world", and this is my first time. There should be no excuses for not giving jhc a whirl. : ) Paulo From john at repetae.net Tue Aug 25 21:13:11 2009 From: john at repetae.net (John Meacham) Date: Tue Aug 25 20:53:02 2009 Subject: [Haskell] ANNOUNCE: jhc 0.7.1 In-Reply-To: <1251206114.30910.8061.camel@localhost> References: <20090825041336.GI18852@sliver.repetae.net> <1251206114.30910.8061.camel@localhost> Message-ID: <20090826011310.GA5620@sliver.repetae.net> On Tue, Aug 25, 2009 at 02:15:14PM +0100, Duncan Coutts wrote: > 1. Would it be possible to have a machine-readable form of: > jhc --list-libraries > > It's possible to parse the output of course but the worry is always that > the format will change again. Good Idea, I'll modify the output to be a proper YAML file with a few guarenteed fields, that will leave room for expansion later and backwards compatability. > 2. In older jhc versions it was possible to specify .hl libraries by > name and version, eg jhc -p filepath-1.0.1.1. In the latest release it > is only possible by name. Is this intentional? I know jhc uses hashes to > uniquely identify installed packages, perhaps it should be possible to > specify packages by hash for the case that one has several instances of > the same package (possibly different versions, or built against > different versions of various dependencies). Ah, this is an unintentional regression. I intended to keep the behavior of being able to specify a library name/version or file name. Being able to specify a hash is also a good idea. > like when there are several packages of the same version but with a > different hash? Maybe a machine readable --list-libraries should list > the hash too. > > > 4. Is there a way to get back the library/package description that jhc > bakes into the .hl files? There's a --show-ho. Perhaps we want a > --show-hl that dumps the library description? I guess that should also > tell us the package hash. --show-ho will also work on hl files, which probably isn't mentioned anywhere in the manual. I think I will add a verbose mode to --list-libraries that will also spit out much of this meta-info (in the aforementioned YAML format) > 5. The ./configure doesn't check for the Haskell readline package. Yeah, I am currently only checking for the purpose of ghc 6.8/6.10 compatibility, but adding checks for all dependencies is a good idea. As an aside, here are the principles that guided the design of the new library system and ho cache. The main motivations were ameliorating two notable shortcomings of jhc, its speed and compatibility with other compilers: * Ho files will only affect speed of compilation, never results. No matter what. This allows the shared ho cache and decoupling the unit of caching from module granularity. * Only the interface of libraries explicitly mentioned on the command line shall affect code compiled by jhc. For instance, a libraries implementation can use an alternate prelude without hurting its compatibility with haskell 98 code. * From the users perspective, a library defines an interface, which is not necessarily coupled to the implementation. I have thought long and hard on the problem of being able to maintain some level of compatibility with ghc and hackage without sacrificing jhc's ability to innovate, or tying its development to the ghc libraries. Making libraries logical 'interfaces' rather than 'implementations' decouples compatibility issues from the compiler itself, anyone can write a library that emulates a particular interface. For instance, a compat-ghc-base3 library might have things like 'Reexport: Compat.Haskell98.Prelude as Prelude, Compat.Ghc.Base3.Monad as Control.Monad, ... '. Or more interestingly, you might create your own library that does a 'Reexport: MyApplicativePrelude as Prelude' to get your own prelude. (this is not fully realized yet in 0.7.1, but will be in a point release soon. The mechanism and framework is there though.) * Stateless. There is no such thing as hidden libraries, libraries mentioned on the command line are available, libraries not mentioned are not. Since libraries can re-export modules this won't cause a command line explosion. For instance, a -phaskell-platform could pull in and make available all the libraries in the haskell platform. * Adding libraries, even incompatible ones, won't break working builds unless said libraries are explicitly mentioned by the build in a non-precise way. This is necessary so a theoretical 'jhc-pkg' tool need only worry about adding required libraries, not cleaning up or worrying about finding consistent sets of libraries. A simple recursive download on dependencies suffices as a rudimentary cabal-install style tool. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From byorgey at seas.upenn.edu Wed Aug 26 18:56:56 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Wed Aug 26 18:36:43 2009 Subject: [Haskell] Haskell Weekly News: Issue 128 - August 26, 2009 Message-ID: <20090826225656.GA13785@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090826 Issue 128 - August 26, 2009 --------------------------------------------------------------------------- Welcome to issue 128 of HWN, a newsletter covering developments in the [1]Haskell community. New releases of haddock, gitit, jhc, formlets, and lots of other libraries and tools; Edinburgh Hack Day, ICFP, and HacPDX coming up; exciting times! The Google Summer of Code has also wrapped up. See below for final progress reports from this summer's Haskell participants. PS: Just as this was going to press, Thomas Ten Cate released the Scion library from his Google Summer of Code project; hence it isn't listed below but you should check it out anyway! Announcements GLUT 2.2.1.0. Sven Panne [2]announced a new version of the [3]GLUT package. The package is now autoconf-free, with API entries are resolved dynamically at runtime; support for sRGB framebuffers has been added; and support for context profiles has been added. Potential Network SIG. Thomas DuBuisson [4]announced the formation of a SIG to hammer out a design for a new Network API, seeing as the current API, a straight-forward Berkeley binding, doesn't seem to please anyone in a Haskell context. epoll bindings 0.1.1. Toralf Wittner [5]announced the release of [6]epoll bindings 0.1.1. Epoll is an I/O event notification facility for Linux similar to poll but with good scaling characteristics. Currently the bindings are fairly low level and close to the C API, but there are plans to add some buffer or stream abstraction on top. Eventually, when GHC can make use of epoll/kqueue in addition to select, this library will not be needed anymore. Until then it might be useful for applications which monitor large numbers of file descriptors. gitit 0.6.1. John MacFarlane [7]announced the release of [8]gitit 0.6.1, a wiki program that runs on happstack, the Haskell web application server stack, and stores pages and other content in a git or darcs filestore. The whole code base has been overhauled since the last release: gitit is now faster, more memory efficient, more modular, and more secure. It also has many new features, including page metadata and categories, atom feeds (sitewide and per-page), support for literate Haskell, a better configuration system, an improved caching system, a Haskell library exporting happstack wiki handlers, and a plugin system. jhc 0.7.1. John Meacham [9]announced the 0.7.1 release of the [10]jhc optimizing Haskell compiler. There have been a lot of changes since the last public release. Some notable ones include the use of a general compiler cache by default rather than object files; reworked library support; an updated manual, with clearer build instructions; support for writing pure C libraries in Haskell; numerous library updates; smart progress meters; typechecking before compilation; and various bug fixes and cross compilation improvements. rss2irc 0.3 released. Simon Michael [11]announced the release of [12]rss2irc version 0.3, an irc bot created by Don Stewart to watch rss feeds and announce new items on irc, now maintained by Simon. This version includes reliable http networking, irc flood protection, better error handling & reporting, extensive debugging output, Atom support, more useful defaults, precise control of irc output, and is now installable on OSX. Feedback and patches welcome. formlets 0.6. Chris Eidhof [13]announced that the formlets team has released a new version of [14]formlets, a library to build type-safe, composable web forms. Most notably, Mightybyte and Chris worked on the [15]massInput functionality, which is now ready for use! graphtype -- A simple tool to illustrate dependencies between Haskell types. Max Desyatov [16]announced the release of [17]graphtype, a tool for visualising type declarations in Haskell source files. It produces [18].dot-files for subsequent processing with graphviz. OAuth library in haskell. Diego Souza [19]announced the release of [20]hoauth, a library which helps you to deal with the [21]oauth protocol. Currently it supports only consumer side applications, but there are plans to add service providers support in near future. ByteString Nums. Jason Dusek [22]announced [23]bytestring-nums, a simple package for relatively careless parsing of numbers from ByteStrings. It works to parse out integer strings, floating point strings and hex strings. haskell-src-exts-1.1.3. Niklas Broberg [24]announced the release of [25]haskell-src-exts-1.1.3, a package for Haskell source code manipulation. It handles (almost) all syntactic extensions to the Haskell 98 standard implemented by GHC, and the parsing can be parametrised on what extensions to recognise. haskell-src-exts-1.1.3 is a highly experimental release, which does not change the current stable part of haskell-src-exts. But it includes a whole new set of modules implementing a new and more accurate syntax tree where all nodes are adorned with annotations. Together with this comes a parser that retains exact source information, stored in the aforementioned annotations. Help in testing and bug reporting is welcome and appreciated! ministg-0.2, an interpreter for STG operational semantics. Bernie Pope [26]announced the first public release of [27]Ministg, an interpreter for a high-level, small-step, operational semantics for the STG machine, the abstract machine at the core of GHC. One of the main features of Ministg is the ability to record a trace of the execution steps as a sequence of HTML files; here is an [28]example trace. OpenCLRaw 1.0.1000. Jeff Heard [29]announced the release of [30]OpenCLRaw, a raw binding to the OpenCL, a platform for single-host heterogeneous, data-parallel computing. He has future plans to create higher-level bindings on top of these raw ones. compose-trans-0.0. Miguel Mitrofanov [31]announced [32]compose-trans, a small library intended to make monad transformers composable. Haddock version 2.5.0. David Waern [33]announced the release of [34]Haddock 2.5.0. This version reverts to the old multi-page index for large packages, shows GADT records in the generated documentation, adds a --use-unicode flag for displaying prettier versions of common symbols, and many other changes. Edinburgh Meetup (Sat 29 Aug) and Hack Day (Sun 30 Aug). Eric Kow [35]sent a reminder that we will be having a [36]Hack Day in Edinburgh on Sunday 30 August at the ICFP venue. There will also be a meetup the day before, 09:30 Saturday 29 August just outside the ICFP venue; we'll have a quick wander and hopefully find some nice places to sit and chat, whip out the occasional laptop and fling a lambda or not being careful not to injure the passers-by. Cleaner networking API - network-fancy. Taru Karttunen [37]announced [38]network-fancy, which offers a cleaner API to networking facilities in Haskell. It supports high-level operations on tcp, udp and unix sockets. Feedback on the API is welcome! GLFW-0.4.1. Paul L [39]announced a new version of [40]GLFW, 0.4.1. Notable changes include a workaround for a FFI bug that affects GHC < 6.10 on 64-bit machines, a fix for the compilation problem on OS X for GHC > 6.10.1, a compatibility fix to work with both OpenGL 2.3.0.0 and older versions, choice of a "dynamic" flag to link with dynamic GLFW C library instead, and a number of other fixes, cleanups and improvements. HacPDX, A Hackathon in Portland. Thomas DuBuisson [41]announced [42]HacPDX, an opportunity for Portland Haskell hackers to join together in building and improving libraries and tools. If you've never been, hackathons are typically not only a good opportunity for experienced devs to work together but also a great way for newcomers to get involved in the community. HacPDX will take place Friday September 25 to Sunday September 27 at Portland State University; see the email for more specific details. Hack on the Delve core, with Delve and Haskell. spoon [43]announced [44]Delve, a new programming language intended to bring the benefits of static type checking and functional programming to object-oriented design and development, currently being implemented in Haskell. Contributors welcome! cabal-query 0.1. Max Desyatov [45]announced the release of [46]cabal-query, a package to assist in finding a set of Cabal packages which satisfy your needs. EnumMap-0.0.1. John Van Enk [47]announced the first version of [48]EnumMap, a generalization of IntMap that constrains the key to Enum rather than forcing it to be Int. Google Summer of Code Progress updates from participants in the 2008 [49]Google Summer of Code. Haddock improvements! Isaac Dupree has [50]wrapped up his project, with patches waiting to be merged back into both Haddock and GHC. His final post contains a detailed description of the work he did; looks like we'll have much better cross-package documentation support in Haddock soon! EclipseFP. Thomas Ten Cate began adding a notion of [51]build targets to EclipseFP, so that projects can be created without .cabal files. He has [52]wrapped up the project for now, and although he isn't fully happy with the results that he achieved, he was able to make useful contributions which hopefully others can continue to build on. Improving the Haskell space profiling experience. Gergely Patai's project is done: he [53]uploaded hp2any, a set of realtime space profiling tools, to Hackage. He also [54]created a [55]haskellwiki page describing it and its use. haskell-src-exts -> haskell-src. Niklas Broberg has been [56]working on a complete revamp of the AST, lexer and parser to allow for exact source info to be kept in the tree, which in turn will allow exact printing of the code as it was read. darcs. Petr Rockai posted a [57]final report where he described his accomplishments: the hashed-storage library for reading and writing filesystem trees in hash-based formats; darcs whatsnew integration with hashed-storage; progress on a new and improved version of hashed-storage, and a branch of darcs depending on it; and darcs-benchmark, a standalone package for benchmarking darcs. Discussion Unification and matching in Abelian groups. John D. Ramsdell [58]shared some code implementing unification and matching in Abelian groups. Grouping and SIMD in parallel Haskell (using Nested Data Parallel Haskell ideas in legacy code). Zefirov Sergey [59]posted some code showing how to translate Parallel Haskell programs (expressed with par and pseq) into Nested Data Parallel Haskell. Request for Comments - hscurrency 0.0.1. Max Cantor [60]requested feedback on some simple tools to do safe calculations on different currencies. DDC compiler and effects; better than Haskell? (was Re: unsafeDestructiveAssign?). Peter Verswyvelen began a long [61]discussion about the DDC compiler and its effect system, and the relationship to Haskell and monads. Jobs Credit Suisse is hiring. Ganesh Sittampalam [62]announced that the Global Modelling and Analytics Group (GMAG) at Credit Suisse is once again looking to hire functional programmers; see his email for more information. Jane Street is Hiring (as if you didn't already know). Yaron Minsky sent out a [63]reminder that [64]Jane Street is looking to hire functional programmers; see his email for more details. He also mentioned that he will be at parts of ICFP, CUFP and DEFUN this year, so if you're interested, come and talk to him there. Galois is Hiring. Don Stewart [65]announced that Galois is continuing to hire, with multiple positions for talented functional programmers (with both junior and senior positions). They will be at ICFP and related events; see Don or Lee Pike. Blog noise [66]Haskell news from the [67]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * Isaac Dupree: [68]Summer of Code Wrap-Up.. * Thomas ten Cate: [69]Endgame. * Jeff Heard: [70]Followup to my earlier post on Hilbert curve timeseries plots. * Jeff Heard: [71]Plotting timeseries in space filling curves. * Magnus Therning: [72]Making a choice from a list in Haskell, Vty (part 5, the last one). * Magnus Therning: [73]Fork/exec in Haskell. * Edward Kmett: [74]Iteratees, Parsec and Monoids (Slides). * Chris Smith: [75]Flow Equivalence Code in Haskell. * Thomas Ten Cate: [76]Build targets. * Chris Smith: [77]Catching a Mathematical Error Using Haskell's Type System. * Well-Typed: [78]Industrial Haskell Group meeting at CUFP. * London HUG: [79]Next meeting: Alex McLean, Live coding music with Haskell. * David Amos: [80]Finite fields, part 1. * Greg Bacon: [81]Simple analogy for lazy evaluation . * Magnus Therning: [82]JSON in Haskell. * Notes on the LHC: [83]Status update: New Integer implementation.. * Edward Kmett: [84]Clearer Reflections. * Petr Rockai: [85]soc final report. * Gergely Patai: [86]hp2any overview online. * Brent Yorgey: [87]New 2D text layout library. * Manuel Chakravarty: [88]World's first formal machine-checked proof of a general-purpose operating system kernel.. * Bryan O'Sullivan: [89]Haskell Platform support for Fedora: we're almost there. * Gergely Patai: [90]hp2any on Hackage. * Doug Beardsley: [91]Dynamic List Formlets in Haskell . * Niklas Broberg: [92]Quick update. * Christopher Lane Hinson: [93]FactoryArrow. * Michael Feathers: [94]Imposing the Edges Later . * Brent Yorgey: [95]Species operations: differentiation. * >>> Ron Leisti: [96]A prime number sieve in Haskell. Quotes of the Week * bos: You don't get accurate answers from Perl. It just lies to you to keep you happy. * ray: haskell' will come out in 2020 and be h98 with hierarchical modules * ray: enlarge your kleisli arrow, please the category ladies * quicksilver: making the compiler writer's job painful is one of the main duties of a language designer. * gwern: as a plugin, yes, but that's like being so out of shape that a guy in a wheelchair can outrace you - yes, he needs a tool, but you should still be ashamed of yourself * Cale's Lemma: Any sufficiently long string of operator symbols looks like a fish. * randomwords: How "complete" does an application before it's OK to upload to hackage? there are no standards lawless wasteland. Got it. * ndm: I was browsing through the Yhc standard libraries, as one does on the weekend, and was drawn to Yhc's sort function. * michaelfeathers: I did a parody post to Haskell Cafe last year where I had some code that was calling (nub . nub) zip12 and asked if there was a zip13 and no one called it out as a joke. About the Haskell Weekly News New editions are posted to [97]the Haskell mailing list as well as to [98]the Haskell Sequence and [99]Planet Haskell. [100]RSS is also available, and headlines appear on [101]haskell.org. To help create new editions of this newsletter, please see the information on [102]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [103]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.general/17442 3. http://hackage.haskell.org/package/GLUT 4. http://article.gmane.org/gmane.comp.lang.haskell.libraries/11813 5. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62782 6. http://hackage.haskell.org/package/epoll 7. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62776 8. http://gitit.johnmacfarlane.net/ 9. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62759 10. http://repetae.net/computer/jhc 11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62743 12. http://hackage.haskell.org/package/rss2irc 13. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62738 14. http://hackage.haskell.org/package/formlets 15. http://softwaresimply.blogspot.com/2009/08/dynamic-list-formlets-in-haskell.html 16. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62736 17. http://hackage.haskell.org/package/graphtype 18. http://i.piccy.info/i4/00/90/bfa07290012c2d3b455696bdaa86.png 19. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62735 20. http://hackage.haskell.org/package/hoauth 21. http://oauth.net/ 22. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62695 23. http://hackage.haskell.org/package/bytestring-nums 24. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62682 25. http://hackage.haskell.org/package/haskell-src-exts 26. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62559 27. http://www.haskell.org/haskellwiki/Ministg 28. http://www.cs.mu.oz.au/~bjpop/trace/step0.html 29. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62414 30. http://hackage.haskell.org/package/OpenCLRaw 31. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62390 32. http://hackage.haskell.org/package/compose%2Dtrans 33. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62341 34. http://www.haskell.org/haddock 35. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62324 36. http://www.haskell.org/haskellwiki/Hac7 37. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62277 38. http://hackage.haskell.org/package/network%2Dfancy 39. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62259 40. http://hackage.haskell.org/package/GLFW 41. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62195 42. http://haskell.org/haskellwiki/HacPDX 43. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62173 44. http://killersmurf.blogspot.com/ 45. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62139 46. http://hackage.haskell.org/package/cabal%2Dquery 47. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62119 48. http://hackage.haskell.org/package/EnumMap 49. http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2008 50. http://haddock2009.wordpress.com/2009/08/26/summer-of-code-wrap-up/ 51. http://eclipsefp.wordpress.com/2009/08/20/build-targets/ 52. http://eclipsefp.wordpress.com/2009/08/25/endgame/ 53. http://just-bottom.blogspot.com/2009/08/hp2any-on-hackage.html 54. http://just-bottom.blogspot.com/2009/08/hp2any-overview-online.html 55. http://www.haskell.org/haskellwiki/Hp2any 56. http://nibrofun.blogspot.com/2009/08/just-quick-note-since-i-realise-i.html 57. http://web.mornfall.net/blog/soc_final_report.html 58. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/62486 59. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/62403 60. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/62342 61. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/62205 62. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62406 63. http://article.gmane.org/gmane.comp.lang.haskell.general/17436 64. http://www.janestreet.com/ 65. http://article.gmane.org/gmane.comp.lang.haskell.cafe/62191 66. http://planet.haskell.org/ 67. http://haskell.org/haskellwiki/Blog_articles 68. http://haddock2009.wordpress.com/2009/08/26/summer-of-code-wrap-up/ 69. http://eclipsefp.wordpress.com/ 70. http://vis.renci.org/jeff/2009/08/24/followup-to-my-earlier-post-on-hilbert-curve-timeseries-plots/ 71. http://vis.renci.org/jeff/2009/08/24/plotting-timeseries-in-space-filling-curves/ 72. http://therning.org/magnus/archives/732 73. http://therning.org/magnus/archives/727 74. http://comonad.com/reader/2009/iteratees-parsec-and-monoid/ 75. http://cdsmith.wordpress.com/2009/08/20/flow-equivalence-code-in-haskell/ 76. http://eclipsefp.wordpress.com/2009/08/20/build-targets/ 77. http://cdsmith.wordpress.com/2009/08/19/catching-a-mathematical-error-using-haskells-type-system/ 78. http://blog.well-typed.com/2009/08/industrial-haskell-group-meeting-at-cufp/ 79. http://www.londonhug.net/2009/08/18/next-meeting-alex-mclean-live-coding-music-with-haskell/ 80. http://haskellformaths.blogspot.com/2009/08/finite-fields-part-1.html 81. http://gbacon.blogspot.com/2009/08/simple-analogy-for-lazy-evaluation.html 82. http://therning.org/magnus/archives/719 83. http://lhc-compiler.blogspot.com/2009/08/status-update-new-integer.html 84. http://comonad.com/reader/2009/clearer-reflection/ 85. http://web.mornfall.net/blog/soc_final_report.html 86. http://just-bottom.blogspot.com/2009/08/hp2any-overview-online.html 87. http://byorgey.wordpress.com/2009/08/14/new-2d-text-layout-library/ 88. http://justtesting.org/post/162408446/worlds-first-formal-machine-checked-proof-of-a 89. http://www.serpentine.com/blog/2009/08/12/haskell-platform-support-for-fedora-were-almost-there/ 90. http://just-bottom.blogspot.com/2009/08/hp2any-on-hackage.html 91. http://softwaresimply.blogspot.com/2009/08/dynamic-list-formlets-in-haskell.html 92. http://nibrofun.blogspot.com/2009/08/just-quick-note-since-i-realise-i.html 93. http://blog.downstairspeople.org/2009/08/09/factoryarrow/ 94. http://blog.objectmentor.com/articles/2009/08/08/imposing-the-edges-later 95. http://byorgey.wordpress.com/2009/08/05/species-operations-differentiation/ 96. http://www.ronleisti.com/wp/2009/07/26/a-prime-number-sieve-in-haskell/ 97. http://www.haskell.org/mailman/listinfo/haskell 98. http://sequence.complete.org/ 99. http://planet.haskell.org/ 100. http://sequence.complete.org/node/feed 101. http://haskell.org/ 102. http://haskell.org/haskellwiki/HWN 103. http://code.haskell.org/~byorgey/code/hwn/ From a.serebrenik at tue.nl Thu Aug 27 16:26:26 2009 From: a.serebrenik at tue.nl (Serebrenik, A.) Date: Thu Aug 27 16:06:44 2009 Subject: [Haskell] SLE 2009 Denver Colorado - Call for participation In-Reply-To: <7DF2365FF07C0E4E89419D65CCC93C9E0160CFC4F7FC@EXCHANGE11.campus.tue.nl> References: <7DF2365FF07C0E4E89419D65CCC93C9E0160CFC4F7F4@EXCHANGE11.campus.tue.nl>, <7DF2365FF07C0E4E89419D65CCC93C9E0160CFC4F7F7@EXCHANGE11.campus.tue.nl>, <7DF2365FF07C0E4E89419D65CCC93C9E0160CFC4F7FA@EXCHANGE11.campus.tue.nl>, <7DF2365FF07C0E4E89419D65CCC93C9E0160CFC4F7FC@EXCHANGE11.campus.tue.nl> Message-ID: <7DF2365FF07C0E4E89419D65CCC93C9E0160CFC4F7FE@EXCHANGE11.campus.tue.nl> ___________________________________________________________ Call for Participation - SLE 2009 2nd International Conference on Software Language Engineering http://planet-sl.org/sle2009 Denver, Colorado, October 5-6, 2009 ____________________________________________________________ Co-located with 12th International Conference on Model-Driven Engineering Languages and Systems (MODELS 2009) and 8th International Conference on Generative Programming and Component Engineering (GPCE 2009) Highlights: - Research Program: 15 research papers, 6 short papers and 2 tool demos (program listed below) - Keynote Speakers: Jean Bezivin and James Cordy - Early Registration: Open until Sept 14, 2008 Conference ---------- The 2nd International Conference on Software Language Engineering (SLE) is devoted to topics related to artificial languages in software engineering. SLE's foremost mission is to encourage and organize communication between communities that have traditionally looked at software languages from different, more specialized, and yet complementary perspectives. SLE emphasizes the fundamental notion of languages as opposed to any realization in specific "technical spaces". SLE 2009 will be co-located with the 12th IEEE/ACM International Conference on Model-Driven Engineering Languages and Systems (MODELS 2009) and 8th International Conference on Generative Programming and Component Engineering (GPCE 2009). Scope ----- The term 'software language' comprises all sorts of artificial languages used in software development, including general-purpose programming languages, domain-specific languages, modeling and meta-modeling languages, data models, and ontologies. Used in its broadest sense, examples include modeling languages such as UML-based and domain-specific modeling languages, business process modeling languages, and web application modeling languages. The term 'software language' also comprises APIs and collections of design patterns that are implicitly defined languages. Software language engineering is the application of a systematic, disciplined, quantifiable approach to the development, use, and maintenance of these languages. Thus, the SLE conference is concerned with all phases of the life cycle of software languages; these include the design, implementation, documentation, testing, deployment, evolution, recovery, and retirement of languages. Of special interest are tools, techniques, methods and formalisms that support these activities. In particular, tools are often based on or even automatically generated from a formal description of the language. Hence, of special interest is the treatment of language descriptions as software artifacts, akin to programs - while paying attention to the special status of language descriptions, subject to tailored engineering principles and methods for modularization, refactoring, refinement, composition, versioning, co-evolution, and analysis. Accepted Papers --------------- Research Papers * August Schwerdfeger and Eric Van Wyk. Verifiable Parse Table Composition for Deterministic Parsing * Fr?d?ric Mallet, Francois Lagarde, Charles Andr?, Sebastien Gerard and Francois Terrier. An Automated Process for implementing Multi-level domain models * Krzysztof Czarnecki, Thiago Tonelli Bartolomei, Ralf Laemmel and Tijs van der Storm. Transcript of an API migration for two XML APIs * Lukas Renggli, Marcus Denker and Oscar Nierstrasz. Language Boxes: Bending the Host Language with Modular Language Changes * Maartje de Jonge, Emma Nilsson-Nyman, Lennart C. L. Kats and Eelco Visser. Natural and Flexible Error Recovery for Generated Parsers * Markus Herrmannsdoerfer, Daniel Ratiu and Guido Wachsmuth. Language Evolution in Practice: The History of GMF * Mathieu Acher, Philippe Collet, Philippe Lahire and Robert France. Composing Feature Models * Mauricio Alferez, Jo?o Santos, Ana Moreira, Alessandro Garcia, Uir? Kulesza, Jo?o Ara?jo and Vasco Amaral. Multi-View Composition Language for Software Product Line Requirements * Nils Thieme, Christian Wende and Steffen Zschaler. A Role-based Approach Towards Modular Language Engineering * Steffen Zschaler, Dimitrios Kolovos, Nicholas Drivalos, Richard Paige and Awais Rashid. Domain-Specific Metamodelling Languages for Software Language Engineering * Steffen Zschaler, Pablo Sanchez, Joao Santos, Mauricio Alferez, Awais Rashid, Lidia Fuentes, Ana Moreira, Joao Araujo and Uira Kulesza. VML* -- A Family of Languages for Variability Management in Software Product Lines * Tihamer Levendovszky, Anantha Narayanan, Daniel Balasubramanian and Gabor Karsai. A Novel Approach to Semi-Automated Evolution of DSML Model Transformation * Tim Bauer and Martin Erwig. Declarative Scripting in Haskell * Uwe Jugel. Generating Smart Wrapper Libraries for Arbitrary APIs * Zef Hemel and Eelco Visser. PIL: A Platform Independent Language for Retargetable DSLs Short papers * Anya Helene Bagge. Yet Another Language Extension Scheme * Daniel Spiewak and Tian Zhao. ScalaQL: Language-Integrated Database Queries for Scala * Danny M. Groenewegen and Eelco Visser. Integration of Data Validation and User Interface Concerns in a DSL for Web Applications * Ivan Kurtev and Alfons Laarman. Ontological Metamodeling with Explicit Instantiation * Jer?nimo Iraz?bal and Claudia Pons. Model transformation languages relying on models as ADTs * Paul Laird and Stephen Barrett. Towards the Dynamic Evolution of Domain Specific Languages Tools * Elina Kalnina, Audris Kalnins, Edgars Celms and Agris Sostaks. Graphical template language for transformation synthesis * Florian Heidenreich, Jendrik Johannes, Mirko Seifert and Christian Wende. Closing the Gap between Modelling and Java Registration ------------ Registration is open now. Early bird registration is open until Sept 14. Regitration is available at: https://register.cce.umn.edu/Course.pl?sect_key=183427 Keynote Speakers ---------------- * James Cordy, Queens University, Canada * Jean Bezivin, INRIA & Ecole des Mines de Nantes, France Organization ------------ Steering Committee * Mark van den Brand, TU Eindhoven, The Netherlands * James Cordy, Queen's University, Canada * Jean-Marie Favre, University of Grenoble, France * Dragan Gasevic, Athabasca University, Canada * Gorel Hedin, Lund University, Sweden * Ralf Laemmel, Universitat Koblenz-Landau, Germany * Eric Van Wyk, University of Minnesota, USA * Andreas Winter, Johannes Gutenberg-Universitat Mainz, Germany General Chair * Dragan Gasevic, Athabasca University, Canada Program Committee Co-Chairs * Mark van den Brand, TU Eindhoven, The Netherlands * Jeff Gray, University of Alabama at Birmingham, USA Program Committee * Colin Atkinson, Universit?t Mannheim, Germany * Don Batory, University of Texas at Austin, USA * Paulo Borba, Universidade Federal de Pernambuco, Brazil * John Boyland, University of Wisconsin, Milwaukee, USA * Marco Brambilla, Politecnico di Milano, Italy * Shigeru Chiba, Tokyo Institute of Technology, Japan * Charles Consel, LaBRI / INRIA, France * Gregor Engels, Universit?t Paderborn, Germany * Stephen A. Edwards, Columbia University, USA * Robert Fuhrer, IBM T.J. Watson Research, USA * Martin Gogolla, University of Bremen, Germany * Giancarlo Guizzardi, Federal University of Esp?rito Santo, Brazil * Reiko Heckel, University of Leicester, UK * Fr?d?ric Jouault, INRIA & Ecole des Mines de Nantes, France * Nicholas Kraft, University of Alabama, USA * Thomas K?hne, Victoria University of Wellington, New Zealand * Julia Lawall, University of Copenhagen, Denmark * Timothy Lethbridge, University Ottawa, Canada * Brian Malloy, Clemson University, USA * Kim Mens, Universit? catholique de Louvain, Belgium * Marjan Mernik, University of Maribor, Slovenia * Todd Millstein, University of California, Los Angeles, USA * Pierre-Etienne Moreau, INRIA Nancy - Grand Est, France * Pierre-Alain Muller, University of Haute-Alsace, France * Daniel Oberle, SAP Research, Germany * Richard Paige, University of York, UK * James Power, National University of Ireland, Ireland * Jo?o Saraiva, Universidade do Minho, Portugal * Mary Lou Soffa, University of Virginia, USA * Juha-Pekka Tolvanen, MetaCase, Finland * Alexander Serebrenik, Eindhoven University of Technology, Netherlands * Tony Sloane, Macquarie University, Australia * Steffen Staab, Universit?t Koblenz-Landau, Germany * Jun Suzuki, University of Massachusetts, Boston, USA * Walid Taha, Rice University, USA * Eli Tilevich, Virginia Tech, USA * Jurgen Vinju, CWI, Netherlands * Eelco Visser, Delft University of Technology, Netherlands * Ren? Witte, Concordia University, Canada Organization Committee * Bardia Mohabbati, Simon Fraser University, Canada (Web Chair) * James Hill, Vanderbilt University, USA (Publicity co-Chair) * Alexander Serebrenik, TU Eindhoven, The Netherlands (Publicity co-Chair) * Eric Van Wyk, University of Minnesota (Finance Chair) From sylvain.nahas at googlemail.com Thu Aug 27 16:52:30 2009 From: sylvain.nahas at googlemail.com (sylvain) Date: Thu Aug 27 16:32:13 2009 Subject: [Haskell] Re: [Haskell-cafe] ANNOUNCE: jhc 0.7.1 In-Reply-To: References: <20090825041336.GI18852@sliver.repetae.net> Message-ID: <1251406350.4998.13.camel@dell.linuxdev.us.dell.com> > There should be no excuses for not giving jhc a whirl. Agreed. In a lot of ways, jhc seems like a Haskell compiler done right. It generates very fast and lean binaries - using C as an intermediary language - which makes it a natural cross-compiler and indicates it should not be too difficult to write a back-end for the CIL and the jvm. On the other hand, it is still far away from GHC features-wise. So there is definitively room for people looking to contribute to a compiler with a high potential. Wouldn't that be fun? Sylvain.