From bulat.ziganshin at gmail.com Mon Jun 1 04:18:27 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Jun 1 04:03:51 2009 Subject: [Haskell] The speed, size and dependability of programming languages Message-ID: <12710665395.20090601121827@gmail.com> Hello haskell, Interesting blog post comparing speed and expressiveness of many languages: http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From marlowsd at gmail.com Mon Jun 1 06:54:59 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jun 1 06:39:03 2009 Subject: [Haskell] Reminder: Haskell Implementers' Workshop CFT deadline in 2 weeks Message-ID: <4A23B383.6020009@gmail.com> Please consider submitting a talk proposal for the Haskell Implementers' Workshop. I'm pretty excited about this meeting - it promises to be a lively and enjoyable day. The deadline for submissions is a couple of weeks away, all you have to do is write an abstract: Call for Talks ACM SIGPLAN Haskell Implementers' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop Edinburgh, Scotland, September 5, 2009 The workshop will be held in conjunction with ICFP 2009 http://www.cs.nott.ac.uk/~gmh/icfp09.html Important dates Proposal Deadline: 15 June 2009 Notification: 3 July 2009 The Haskell Implementers Workshop is a new workshop to be held alongside ICFP 2009 this year in Edinburgh, Scotland. There will be no proceedings; it is an informal gathering of people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure. This new workshop reflects the growth of the user community: there is a clear need for a well-supported tool chain for the development, distribution, deployment, and configuration of Haskell software. The aim is for this workshop to give the people involved with building the infrastructure behind this ecosystem an opportunity to bat around ideas, share experiences, and ask for feedback from fellow experts. We intend the workshop to have an informal and interactive feel, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- We feel it's important to clearly distinguish the Haskell Implementers Workshop from the other Haskell-related workshops co-located with ICFP 2009. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementers' Workshop will have no proceedings - although we will aim to make slides and talk videos available with the consent of the speakers. DEFUN aims to teach how functional programming techniques can be applied in practice. In the Haskell Implementors' Workshop we hope to study the underlying technology that drives this application development. We want to bring together anyone interested in the nitty gritty details necessary to turn a text file into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop - we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics (but there may be some we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets): * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and Tools for development or deployment Talks ----- At this stage we'd like to invite proposals from potential speakers for a relatively short (20-30 min) talk. Please submit a talk title and abstract of no more than 200 words to simonmar@microsoft.com. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. We also plan to invite a number of speakers from the community. Organizers ---------- * Duncan Coutts - co-chair (Well-Typed LLP) * Atze Dijkstra (Utrecht University) * Roman Leshchinskiy (University of New South Wales) * Simon Marlow - co-chair (Microsoft Research) * Bryan O'Sullivan (Linden Lab) * Wouter Swierstra (Chalmers University of Technology) From lists at qseep.net Mon Jun 1 13:58:14 2009 From: lists at qseep.net (Lyle Kopnicky) Date: Mon Jun 1 13:42:34 2009 Subject: [Haskell] The speed, size and dependability of programming languages In-Reply-To: <12710665395.20090601121827@gmail.com> References: <12710665395.20090601121827@gmail.com> Message-ID: <670e468e0906011058l76a6e377hbed1d52a7ed02bc6@mail.gmail.com> Thanks for the link. I find the expressiveness results odd. How can SML/NJ be among the least expressive languages, while MLTON and OCAML are among the most expressive? How is Smalltalk less expressive than Java? Why are Prolog and Mercury among the least expressive? I think it's a combination of 1) the expressiveness measure is too simplistic, measuring number of lines alone, or counting comments, and 2) the problem set is skewed toward number-crunching, which is not (say) Prolog's strong suit. On Mon, Jun 1, 2009 at 1:18 AM, Bulat Ziganshin wrote: > Hello haskell, > > Interesting blog post comparing speed and expressiveness of many > languages: > http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090601/bcd4976d/attachment.html From dons at galois.com Mon Jun 1 13:59:45 2009 From: dons at galois.com (Don Stewart) Date: Mon Jun 1 13:45:32 2009 Subject: [Haskell] The speed, size and dependability of programming languages In-Reply-To: <670e468e0906011058l76a6e377hbed1d52a7ed02bc6@mail.gmail.com> References: <12710665395.20090601121827@gmail.com> <670e468e0906011058l76a6e377hbed1d52a7ed02bc6@mail.gmail.com> Message-ID: <20090601175945.GY30495@whirlpool.galois.com> lists: > I think it's a combination of 1) the expressiveness measure is too simplistic, > measuring number of lines alone, or counting comments It isn't measuring lines of code, it is measuring the Gzip compression Also, there's a few bogons in the data (it was graphed against 2005-6 results, and includes programs that produce the wrong output, and programs where the are duplicate entires per language). -- Don From gwern0 at gmail.com Mon Jun 1 14:16:31 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Mon Jun 1 14:00:38 2009 Subject: [Haskell] The speed, size and dependability of programming languages In-Reply-To: <670e468e0906011058l76a6e377hbed1d52a7ed02bc6@mail.gmail.com> References: <12710665395.20090601121827@gmail.com> <670e468e0906011058l76a6e377hbed1d52a7ed02bc6@mail.gmail.com> Message-ID: On Mon, Jun 1, 2009 at 1:58 PM, Lyle Kopnicky wrote: > Why are Prolog and Mercury among the least expressive? > Well, I don't know about SML/NJ, since I don't see anything obviously wrong at http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=smlnj&lang2=ghc&box=1 But as for Prolog - I can't help but think of a quote I saw in a recent paper in LtU, which went something like 'Our first prototype was written in Prolog, but when we realized that we were using none of the logic programming features, we decided to rewrite in Haskell.' -- gwern From bulat.ziganshin at gmail.com Mon Jun 1 14:09:04 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Jun 1 14:00:50 2009 Subject: [Haskell] The speed, size and dependability of programming languages In-Reply-To: <670e468e0906011058l76a6e377hbed1d52a7ed02bc6@mail.gmail.com> References: <12710665395.20090601121827@gmail.com> <670e468e0906011058l76a6e377hbed1d52a7ed02bc6@mail.gmail.com> Message-ID: <18510368292.20090601220904@gmail.com> Hello Lyle, Monday, June 1, 2009, 9:58:14 PM, you wrote: > Thanks for the link. I find the expressiveness results odd. How can > SML/NJ be among the least expressive languages, while MLTON and > OCAML are among the most expressive? optimization tricks? > How is Smalltalk less > expressive than Java? libraries? > Why are Prolog and Mercury among the least expressive? programming style? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Mon Jun 1 14:17:39 2009 From: dons at galois.com (Don Stewart) Date: Mon Jun 1 14:03:20 2009 Subject: [Haskell] The speed, size and dependability of programming languages In-Reply-To: References: <12710665395.20090601121827@gmail.com> <670e468e0906011058l76a6e377hbed1d52a7ed02bc6@mail.gmail.com> Message-ID: <20090601181739.GB30495@whirlpool.galois.com> gwern0: > On Mon, Jun 1, 2009 at 1:58 PM, Lyle Kopnicky wrote: > > Why are Prolog and Mercury among the least expressive? > > > > Well, I don't know about SML/NJ, since I don't see anything obviously > wrong at http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=smlnj&lang2=ghc&box=1 There's one thing wrong: Last Updated: Tue Mar 20 18:02:38 PDT 2007 Don't use the gp4 results: they're obsolete. Use the u32, u64, u32q or u64q results. -- Don From david at seereason.com Mon Jun 1 14:20:59 2009 From: david at seereason.com (David Fox) Date: Mon Jun 1 14:05:05 2009 Subject: [Haskell] Data.Generics.gzip3 anyone? Message-ID: Is there a Scrap Your Boilerplate guru out there who could whip up a three argument version of gzip for me? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090601/2917cdee/attachment.html From caseyh at istar.ca Mon Jun 1 14:40:15 2009 From: caseyh at istar.ca (Casey Hawthorne) Date: Mon Jun 1 14:24:21 2009 Subject: [Haskell] The speed, size and dependability of programming languages In-Reply-To: <20090601181739.GB30495@whirlpool.galois.com> References: <12710665395.20090601121827@gmail.com> <670e468e0906011058l76a6e377hbed1d52a7ed02bc6@mail.gmail.com> <20090601181739.GB30495@whirlpool.galois.com> Message-ID: <05782551gl6rkvgspga8u7ba7u3eu7rtsh@4ax.com> Instead of GZip metrics for code size, maybe a good measure of imperative language code size would be the "cyclomatic complexity" metric. It would also be interesting to see results for Fortran, Java, C++, etc. across a range of old and newer compilers. Can one measure "cyclomatic complexity" for functional languages? However: From: http://en.wikipedia.org/wiki/Software_metric Modern software development practitioners are likely to point out that naive and simplistic metrics can cause more harm than good. ALSO: one is often more interested in "Software Quality" factors * 4.1.1 Understandability * 4.1.2 Completeness * 4.1.3 Conciseness * 4.1.4 Portability * 4.1.5 Consistency * 4.1.6 Maintainability * 4.1.7 Testability * 4.1.8 Usability * 4.1.9 Reliability * 4.1.10 Structuredness * 4.1.11 Efficiency * 4.1.12 Security Which seem only to be qualitatively "metricable" and not quantitatively "metricable". Benchmarks of any type only seem to be applicable to your program if your program is fairly similar to the benchmark. -- Regards, Casey From rlaemmel at gmail.com Mon Jun 1 15:20:03 2009 From: rlaemmel at gmail.com (Ralf Laemmel) Date: Mon Jun 1 15:04:26 2009 Subject: [Haskell] Data.Generics.gzip3 anyone? In-Reply-To: References: Message-ID: On Mon, Jun 1, 2009 at 8:20 PM, David Fox wrote: > Is there a Scrap Your Boilerplate guru out there who could whip up a three > argument version of gzip for me? This can be done of course (untested but type-checked code follows). Left wondering what the scenario might be :-) Ralf 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 -- 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 From ddssff at gmail.com Mon Jun 1 16:47:47 2009 From: ddssff at gmail.com (David Fox) Date: Mon Jun 1 16:31:49 2009 Subject: [Haskell] Data.Generics.gzip3 anyone? In-Reply-To: References: Message-ID: On Mon, Jun 1, 2009 at 12:20 PM, Ralf Laemmel wrote: > On Mon, Jun 1, 2009 at 8:20 PM, David Fox wrote: > > Is there a Scrap Your Boilerplate guru out there who could whip up a > three > > argument version of gzip for me? > > This can be done of course (untested but type-checked code follows). > Left wondering what the scenario might be :-) > > Ralf > > 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 > > -- 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 > 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. -david -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090601/bfd563b1/attachment.html From rlaemmel at gmail.com Mon Jun 1 18:40:13 2009 From: rlaemmel at gmail.com (Ralf Laemmel) Date: Mon Jun 1 18:24:35 2009 Subject: [Haskell] Data.Generics.gzip3 anyone? In-Reply-To: References: Message-ID: > 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 From ddssff at gmail.com Mon Jun 1 19:35:35 2009 From: ddssff at gmail.com (David Fox) Date: Mon Jun 1 19:19:38 2009 Subject: [Haskell] Data.Generics.gzip3 anyone? In-Reply-To: References: Message-ID: 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 > Oh, thank goodness! -david -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090601/3e09aac4/attachment-0001.html From jpm at cs.uu.nl Tue Jun 2 03:18:42 2009 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Tue Jun 2 03:03:03 2009 Subject: [Haskell] Data.Generics.gzip3 anyone? In-Reply-To: References: Message-ID: <52f14b210906020018l6193d7a6od45e5f6b804ac536@mail.gmail.com> Hello, Would there be interest in having this function added to the SYB library? Thanks, Pedro On Tue, Jun 2, 2009 at 00:40, 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 > _______________________________________________ > 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/20090602/405324b7/attachment.html From voigt at tcs.inf.tu-dresden.de Tue Jun 2 07:18:00 2009 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Tue Jun 2 07:02:02 2009 Subject: [Haskell] HaL4: Haskell-Meeting in Germany, 12th June 2009 Message-ID: <4A250A68.9040105@tcs.inf.tu-dresden.de> Hi all, If you are anyway near Halle/Saale in June, be sure not to miss out on: http://iba-cg.de/hal4.html We have already close to 50 registered participants, so expect a very lively meeting. See you there? (Late registration still possible.) Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From voigt at tcs.inf.tu-dresden.de Tue Jun 2 07:21:17 2009 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Tue Jun 2 07:05:18 2009 Subject: [Haskell] Re: [Haskell-cafe] HaL4: Haskell-Meeting in Germany, 12th June 2009 In-Reply-To: <4A250A68.9040105@tcs.inf.tu-dresden.de> References: <4A250A68.9040105@tcs.inf.tu-dresden.de> Message-ID: <4A250B2D.8090000@tcs.inf.tu-dresden.de> Janis Voigtlaender wrote: > Hi all, > > If you are anyway near Halle/Saale in June, be sure not to miss out on: I meant "anywhere near", of course :-) And even if you are not anyway or anywhere near, you might still want to come just for the occasion :-) -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From paul at cogito.org.uk Tue Jun 2 16:03:10 2009 From: paul at cogito.org.uk (Paul Johnson) Date: Tue Jun 2 15:47:13 2009 Subject: [Haskell] The speed, size and dependability of programming languages In-Reply-To: <670e468e0906011058l76a6e377hbed1d52a7ed02bc6@mail.gmail.com> References: <12710665395.20090601121827@gmail.com> <670e468e0906011058l76a6e377hbed1d52a7ed02bc6@mail.gmail.com> Message-ID: <4A25857E.9040300@cogito.org.uk> Lyle Kopnicky wrote: > > I think it's a combination of 1) the expressiveness measure is too > simplistic, measuring number of lines alone, or counting comments, and > 2) the problem set is skewed toward number-crunching, which is not > (say) Prolog's strong suit. Also there is a strong tendency to optimise the code for performance rather than conciseness (concision?). In the past this tended to bloat (e.g.) Haskell entries as simple intuitive code was replaced by arrays of unboxed integers and similar C-like constructs. From ddssff at gmail.com Tue Jun 2 16:13:26 2009 From: ddssff at gmail.com (David Fox) Date: Tue Jun 2 15:57:27 2009 Subject: [Haskell] Data.Generics.gzip3 anyone? In-Reply-To: References: Message-ID: 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 > Ok, what I initially thought would work is not. I tried to do the three way merge as follows: combine3 :: (Data a) => a -> a -> a -> Maybe a combine3 original left right = gzip3 f original left right where f :: forall a. (Data a) => a -> a -> a -> Maybe a f original left right | geq original left = Just right | geq original right = Just left | geq left right = Just left | otherwise = Nothing However, what happens is that we usually reach the otherwise clause when processing the top level of the data structure, so you get nothing. What really needs to happen is that it traverses down into the data structure and finds out that f is able to merge all the more primitive pieces of the data structure, in which case it combines those merged parts to yield a merged whole. I'm not quite sure how to fit this operation into the generic framework. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090602/633ec709/attachment-0001.html From flippa at flippac.org Tue Jun 2 17:45:18 2009 From: flippa at flippac.org (Philippa Cowderoy) Date: Tue Jun 2 17:29:31 2009 Subject: [Haskell] ANN: Anglohaskell 2009 Message-ID: <1243979118.7090.447.camel@flippa-eee> Anglohaskell 2009 is go! I'm taking on the mantle of organiser, and Microsoft Research have offered us space for talks in Cambridge again. The event will be held on the 7th and 8th of August. More info at http://www.haskell.org/haskellwiki/AngloHaskell/2009 , planning and discussion in #anglohaskell on freenode. For those not familiar with Anglohaskell, it's a somewhat-informal get-together featuring a mixture of talks, discussion and socialising with topics from the hobbyist to the pragmatic to the theoretical. All are welcome, regardless of experience, and best of all - it's free! If anyone wants to offer a talk, help with running the event, accomodation for haskellers from out of town or some ideas, please feel free to edit the wiki page appropriately and/or give us a yell in #anglohaskell. -- Philippa Cowderoy From dons at galois.com Tue Jun 2 18:10:22 2009 From: dons at galois.com (Don Stewart) Date: Tue Jun 2 17:56:03 2009 Subject: [Haskell] ANNOUNCE: The Haskell Platform 2009.2.0.1 Message-ID: <20090602221022.GN4396@whirlpool.galois.com> We're pleased to announce the second release of the Haskell Platform: a single, standard Haskell distribution for everyone. The specification, along with installers (including Windows and Unix installers for a full Haskell environment) are available. Download the Haskell Platform 2009.2.0.1: http://hackage.haskell.org/platform/ The Haskell Platform is a blessed library and tool suite for Haskell distilled from Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. Distro maintainers that support the Haskell Platform can be confident they're fully supporting Haskell as the developers intend it. Developers targetting the platform can be confident they have a trusted base of code to work with. What you get: http://hackage.haskell.org/platform/contents.html With regular time-based releases, we expect the platform will grow into a rich, indispensable development environment for all Haskell projects. Please note that this is a beta release. We do not expect all the installers to work perfectly, nor every developer need met, and we would appreciate feedback. You can help out by packaging the platform for your distro, or reporting bugs and feature requests, or installing Haskell onto your friends' machines. The process for adding new tools and libraries will be outlined in coming weeks. The Haskell Platform would not have been possible without the hard work of the Cabal development team, the Hackage developers and maintainers, the individual compiler, tool and library authors who contributed to the suite, and the distro maintainers who build and distribute the Haskell Platform. Thanks! -- The Platform Infrastructure Team From hjgtuyl at chello.nl Tue Jun 2 18:58:15 2009 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Tue Jun 2 18:42:20 2009 Subject: [Haskell] Re: [Haskell-cafe] ANN: Anglohaskell 2009 In-Reply-To: <1243979118.7090.447.camel@flippa-eee> References: <1243979118.7090.447.camel@flippa-eee> Message-ID: On Tue, 02 Jun 2009 23:45:18 +0200, Philippa Cowderoy wrote: > Anglohaskell 2009 is go! F.A.B. :) -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From lists at qseep.net Tue Jun 2 19:22:46 2009 From: lists at qseep.net (Lyle Kopnicky) Date: Tue Jun 2 19:06:45 2009 Subject: [Haskell] The speed, size and dependability of programming languages In-Reply-To: <4A25857E.9040300@cogito.org.uk> References: <12710665395.20090601121827@gmail.com> <670e468e0906011058l76a6e377hbed1d52a7ed02bc6@mail.gmail.com> <4A25857E.9040300@cogito.org.uk> Message-ID: <670e468e0906021622n5d100d4bk3e63370e4530dbd1@mail.gmail.com> On Tue, Jun 2, 2009 at 1:03 PM, Paul Johnson wrote: > Lyle Kopnicky wrote: > >> >> I think it's a combination of 1) the expressiveness measure is too >> simplistic, measuring number of lines alone, or counting comments, and 2) >> the problem set is skewed toward number-crunching, which is not (say) >> Prolog's strong suit. >> > Also there is a strong tendency to optimise the code for performance rather > than conciseness (concision?). In the past this tended to bloat (e.g.) > Haskell entries as simple intuitive code was replaced by arrays of unboxed > integers and similar C-like constructs. > Well, they're supposedly measuring performance as well. If concise Haskell is non-performant, and performant Haskell is verbose, this ought to be reflected in the charts. But it managed to perform pretty well in both. I don't think Haskell got short shrift in this analysis. Perhaps other languages suffered a more "written verbosely for performance" problem. - Lyle -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090602/bfb9b46f/attachment.html From ddssff at gmail.com Tue Jun 2 19:57:58 2009 From: ddssff at gmail.com (David Fox) Date: Tue Jun 2 19:41:59 2009 Subject: [Haskell] Data.Generics.gzip3 anyone? In-Reply-To: References: Message-ID: On Tue, Jun 2, 2009 at 1:13 PM, David Fox wrote: > 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 >> > > Ok, what I initially thought would work is not. I tried to do the three > way merge as follows: > > combine3 :: (Data a) => a -> a -> a -> Maybe a > combine3 original left right = > gzip3 f original left right > where > f :: forall a. (Data a) => a -> a -> a -> Maybe a > f original left right > | geq original left = Just right > | geq original right = Just left > | geq left right = Just left > | otherwise = Nothing > > However, what happens is that we usually reach the otherwise clause when > processing the top level of the data structure, so you get nothing. What > really needs to happen is that it traverses down into the data structure and > finds out that f is able to merge all the more primitive pieces of the data > structure, in which case it combines those merged parts to yield a merged > whole. I'm not quite sure how to fit this operation into the generic > framework. > Oh, I got it. I have to remove the "f x y z `orElse`" from the definition of gzip3. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090602/23df2cb5/attachment.html From madhadron at gmail.com Wed Jun 3 03:35:57 2009 From: madhadron at gmail.com (Frederick Ross) Date: Wed Jun 3 03:19:55 2009 Subject: [Haskell] A library for serial ports Message-ID: I've just uploaded serial-0.1, a library for line-oriented interaction with serial ports on POSIX compatible systems, to Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/serial At the moment it's just two modules, one of which wraps up the serial connection in a convenience function (System.Serial), and the other (System.Serial.Manager) which further wraps a serial connection in a set of functions to let multiple commands go to a non-blocking device on the far end of the port and, with the proper parsers and a little luck, get the responses sent back to all the right calling functions. The interface is not final yet. I'm using Parsec parsers passed with the command to sort out where return values should go, and that may just become predicates later. Also, if someone who actually knows anything about programming on Windows wants to add that capability, I'd be thrilled. -- Frederick Ross Doctorant, SV/GHI/UPKIN, EPFL Graduate Fellow, The Rockefeller University From ddssff at gmail.com Wed Jun 3 14:42:21 2009 From: ddssff at gmail.com (David Fox) Date: Wed Jun 3 14:26:19 2009 Subject: [Haskell] Data.Generics.gzip3 anyone? In-Reply-To: References: Message-ID: Wait, its much funnier than that. It wouldn't merge the three revisions because they always differed in one field - the revision number! On Tue, Jun 2, 2009 at 4:57 PM, David Fox wrote: > > > On Tue, Jun 2, 2009 at 1:13 PM, David Fox wrote: > >> 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 >>> >> >> Ok, what I initially thought would work is not. I tried to do the three >> way merge as follows: >> >> combine3 :: (Data a) => a -> a -> a -> Maybe a >> combine3 original left right = >> gzip3 f original left right >> where >> f :: forall a. (Data a) => a -> a -> a -> Maybe a >> f original left right >> | geq original left = Just right >> | geq original right = Just left >> | geq left right = Just left >> | otherwise = Nothing >> >> However, what happens is that we usually reach the otherwise clause when >> processing the top level of the data structure, so you get nothing. What >> really needs to happen is that it traverses down into the data structure and >> finds out that f is able to merge all the more primitive pieces of the data >> structure, in which case it combines those merged parts to yield a merged >> whole. I'm not quite sure how to fit this operation into the generic >> framework. >> > > Oh, I got it. I have to remove the "f x y z `orElse`" from the definition > of gzip3. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090603/dd4d5735/attachment.html From gwern0 at gmail.com Thu Jun 4 12:52:58 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Thu Jun 4 12:36:59 2009 Subject: [Haskell] ANN: wp-archivebot 0.1 - archive Wikipedia's external links in WebCite Message-ID: I'd like to announce wp-archivebot. # What wp-archivebot is a relatively simple little script which follows all the links in a RSS feed, combs the destination for http:// links, and submits them to WebCite. WebCite https://secure.wikimedia.org/wikipedia/en/wiki/WebCite is an organization much like the more famous Internet Archive. Unlike the Wayback Machine, however, WebCite will archive pages on-demand.* # Why This is good, since link-rot and 404 errors are a fact of life on Wikipedia. Links go stale, fall dead, get banned, edited, censored, etc. If those links are being used as a reference for some important fact or detail, then there is a very big problem. Even the hit-or-miss Internet Archive has proven to be very useful for editors**, so a more reliable way of archiving links would be even better. # Limitations The WebCite FAQhttp://webcitation.org/faq mentions that a good project would be to > develop a wikipedia bot which scans new wikipedia articles for cited URLs, submits an archiving request to WebCite?, and then adds a link to the archived URL behind the cited URL Adding a link would be both quite difficult and require community approval; further, although I have thought about this for years, there's no obvious good way to add a link. Any method is either visually awkward, possibly otiose (if [[Google]] links to google.com as the homepage in its infobox, there's no purpose to have an archived version of google.com!), and certainly will bloat up the markup - even if there's any way to insert links without bolloxing templates and other such constructs. So I'm satisfied to just archive the link. WebCite is searchable, after all. If enough people run bots like this and achieve enough coverage, then perhaps editors can be educated to always check in WebCite as well. # Download & Install As ever, wp-archivebot is Free and is available from Hackage at: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wp-archivebot You can install with ease by a simple 'cabal install wp-archivebot', or download the tarball and compile it yourself with the usual 'runhaskell Setup configure && runhaskell Setup build && runhaskell Setup install' dance. # Usage wp-archivebot takes one mandatory argument, an email address; WebCite needs to have somewhere to send notices of archival success/failure. wp-archivebot takes a second, optional, argument. This is a RSS feed to use. It defaults to Special:NewPages on the English Wikipedia, but one could just as well follow, say, RecentChanges. Here's an example: > wp-archivebot gwern0@gmail.com 'http://en.wikipedia.org/w/index.php?title=Special:RecentChanges&feed=rss' (This sets my email address as the recipient, and follows RecentChanges. This may not be a good idea as RecentChanges is *much* busier than NewPages.) ## Example Here's an example session's output: [12:35 PM] 829Mb$ wp-archivebot gwern0@gmail.com "http://www.webcitation.org/archive?url=http://en.wikisource.org/wiki/Berkeley,_George,_first_earl_of_Berkeley_(DNB00)&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.baseball-reference.com/players/u/uhaltfr01.shtml&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.baseball-reference.com/players/u/uhaltfr01.shtml&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.baseball-reference.com/minors/player.cgi?id=uhalt-001ber&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.baseball-reference.com/minors/player.cgi?id=uhalt-001ber&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.timesargus.com/apps/pbcs.dll/article?AID=/20080509/FEATURES02/805090316/1011/FEATURES02&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.timesargus.com/apps/pbcs.dll/article?AID=/20080509/FEATURES02/805090316/1011/FEATURES02&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.timesargus.com/apps/pbcs.dll/article?AID=/20080509/FEATURES02/805090316/1011/FEATURES02&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.timesargus.com/apps/pbcs.dll/article?AID=/20080509/FEATURES02/805090316/1011/FEATURES02&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.erniestires.net/&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.erniestires.net/&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://thepeerage.com/p4893.htm#i48927&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://thepeerage.com/p4893.htm#i48927&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.leighrayment.com/commons/Acommons3.htm&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.leighrayment.com/commons/Acommons3.htm&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://thepeerage.com/p4893.htm#i48927&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://thepeerage.com/p4893.htm#i48927&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.esec.edu&email=gwern0@gmail.com" "http://www.webcitation.org/archive?url=http://www.esec.edu&email=gwern0@gmail.com" ... # Related The development version (HEAD) of the Gitit wiki has plugin support; one of those plugins, WebArchiver.hs, will on every page-save comb through for off-wiki links and submit them to WebCite in the same way as this bot. It's nice to know that if those links ever disapear, you can retrieve them from WebCite and 'see' the revision with the same set of external links as when the revision was created. * Technically, the Internet Archive will archive on demand as well - but you need to pay them. ** In many more ways than one might expect. For example, not infrequently someone will visit an article and claim it is plagiarizing some other webpage. With the IA, it's easy to go back to the first version of that webpage and crosscheck against the article's history - quite often it is the other website that plagiarized us! -- gwern From oleg at okmij.org Fri Jun 5 04:26:16 2009 From: oleg at okmij.org (oleg@okmij.org) Date: Fri Jun 5 04:11:20 2009 Subject: [Haskell] Safe and generic printf with C-like format string Message-ID: <20090605082616.8D50217702@Adric.metnet.navy.mil> The familiar printf is unsafe: nothing prevents us from passing to printf more or fewer arguments than required by the format specification, or passing the arguments of wrong types. The error is discovered only at run-time. The implementation of printf in Haskell, alas, retains this problem. There is also a desire to better integrate printf with Show, so we can format the value of any showable type: we'd like to have something like the ~a specification of Common Lisp. Integrating printf with show, thus making it generic, is quite easy. The implementation is still Haskell98. It has just been posted: http://www.haskell.org/pipermail/haskell-cafe/2009-June/062410.html Given its simplicity, one may wonder why it was not mentioned in the Haskell98 report or included in standard libraries. The safety problem still remains: we'd like to prevent the mismatch between the arguments of printf and the format specification statically. That too is easy to accomplish. Type-safe printf has been described by Olivier Danvy back in 1998. It is part of SML/NJ. The only remaining bit is to convert the formatting _string_ to the more representative and more useful to the type-checker form. That too is easy, with Template Haskell (as Ryan Ingram remarked). The following code implements that suggestion. Aside from the use of template Haskell, it is Haskell98. Beside the familiar format specifications %s and %d, in implements the specification %a to format any showable value. The code is available at http://okmij.org/ftp/typed-formatting/TotalPrintF.hs http://okmij.org/ftp/typed-formatting/TFTest.hs The second file contains these examples: module TFTest where import TotalPrintF t1 = printf $(spec "Hello, there!") -- "Hello, there!" t2 = printf $(spec "Hello, %s!") "there" -- "Hello, there!" t3 = printf $(spec "The value of %s is %d") "x" 3 -- "The value of x is 3" -- Mismatch between the formatting string and the printf arguments -- is a type error. -- t31 = printf $(spec "The value of %s is %d") "x" True -- Couldn't match expected type `Bool' against inferred type `Int' {- t32 = printf $(spec "The value of %s is %d") "x" 3 10 Couldn't match expected type `t1 -> t' against inferred type `String' Probable cause: `printf' is applied to too many arguments -} t4 = let x = [9,16,25] i = 2 in printf $(spec "The element number %d of %a is %a") i x (x !! i) -- "The element number 2 of [9,16,25] is 25" From ddssff at gmail.com Fri Jun 5 10:08:50 2009 From: ddssff at gmail.com (David Fox) Date: Fri Jun 5 09:52:45 2009 Subject: [Haskell] Data.Generics.gzip3 anyone? In-Reply-To: <52f14b210906020018l6193d7a6od45e5f6b804ac536@mail.gmail.com> References: <52f14b210906020018l6193d7a6od45e5f6b804ac536@mail.gmail.com> Message-ID: I definitely think these functions should be added to syb. I certainly could not have written them myself without hours, perhaps days, of study. 2009/6/2 Jos? Pedro Magalh?es > Hello, > > Would there be interest in having this function added to the SYB library? > > > Thanks, > Pedro > > On Tue, Jun 2, 2009 at 00:40, 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 >> _______________________________________________ >> 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/20090605/eeb24263/attachment-0001.html From madhadron at gmail.com Fri Jun 5 12:39:50 2009 From: madhadron at gmail.com (Frederick Ross) Date: Fri Jun 5 12:23:43 2009 Subject: [Haskell] hscamwire, for IIDC1394 cameras Message-ID: hscamwire 0.1 is now on Hackage. It provides a nice Haskellized layer over Camwire, a library to connect to IIDC1394 cameras (most scientific and industrial Firewire cameras) on Linux. The binding exposes all of Camwire's functionality, except that the only mode for fetching frames is 16-bit monochrome. Adding more modes is quite easy, but this is all I use. If you have a need for another mode, email me and I'll add it. There is no documentation in the package at the moment. I will release a new version fairly soon once I have Haddock'd it, but there is a lot of detail in clib/camwire/camwire.h on the C side, and it translates nearly directly to the Haskell side. Camwire itself is kind of in flux right now as its author upgrades to a new underlying subsystem. As a result, I provide camwire 0.8.1 in a subdirectory (clib/) along with a Makefile to build and install it. When you compile code linking to hscamwire, you'll have to also link against camwire_1394. -- Frederick Ross Doctorant, SV/GHI/UPKIN, EPFL Graduate Fellow, The Rockefeller University From byorgey at seas.upenn.edu Sat Jun 6 14:51:35 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Jun 6 14:35:25 2009 Subject: [Haskell] Haskell Weekly News: Issue 120 - June 6, 2009 Message-ID: <20090606185134.GA3394@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090606 Issue 120 - June 06, 2009 --------------------------------------------------------------------------- Welcome to issue 120 of HWN, a newsletter covering developments in the [1]Haskell community. Sorry for the massive HWN, I missed last week so you're getting two for the price of one! Registration for [2]Hac phi is now open, be sure to register soon (register by June 15 to get a special hotel rate). Announcements Reminder: Haskell Implementers' Workshop CFT deadline in 2 weeks. Simon Marlow [3]reminded everyone to consider submitting a talk proposal for the Haskell Implementers' Workshop, to be held in conjunction with ICFP in Edinburgh, Scotland on 5 September. The deadline for submissions is a couple of weeks away (15 June); all that is needed is an abstract. storable-record. Henning Thielemann [4]announced [5]storable-record, a small package for simplified declaration of Storable instances for records. It may be used as an alternative to the [6]c2hs preprocessor. It was made possible by advanced applicative technology, a cutting edge LCM monoid and an incredible constructor power tower. Haskell Communities and Activities Report (16th ed., May 2009). Janis Voigtlaender [7]announced the availability of the [8]16th Haskell Communities and Activities Report. hledger 0.5 released. Simon Michael [9]announced the release of version 0.5 of [10]hledger, a (mostly) text-mode double-entry accounting tool that generates precise activity and balance reports from a plain text journal file. New repository and trac for haskell-src-exts. Niklas Broberg [11]announced some new infrastructure for the haskell-src-exts package, set up in preparation for his GSoC project. with the HSP packages, it's now old enough to be allowed to [12]live on its own. There is also a [13]bug tracker. Please help by reporting any bugs you come across, or by requesting new and cool features. bsd-sysctl 1.0.3. Maxime Henrion [14]announced the release of [15]bsd-sysctl 1.0.3, a package that provides a System.BSD.Sysctl module allowing access to the C sysctl(3) API. It should fully work on FreeBSD, NetBSD and Mac OS X platforms. multirec-binary. Sebastiaan Visser [16]announced the release of [17]multirec-binary, which allows generic derivation of Data.Binary instances using the [18]MultiRec library. notice for package authors. Duncan Coutts [19]announced that Hackage uploads will soon require an upper bound on the version of the base package and reject packages that omit it. This will hopefully result in less breakage the next time a new version of the base package is released. (Pre-) Announce: Data.GDS 0.1.0. Uwe Hollerbach [20](pre-) announced Data.GDS, a small module to write and (eventually) read GDS files, a classic format of the semiconductor industry. The module can currently generate GDS files with a fairly low-level interface; planned future versions (which will be uploaded to Hackage) will have a higher-level interface and be able to parse GDS files as well. new version of uu-parsinglib. S. Doaitse Swierstra [21]announced that a new version of the [22]uu-parsinglib library has been uploaded to hackage. It is now based on Control.Applicative where possible. Be warned that functions like some and many will be redefined in the future. Hac phi: Haskell hackathon in Philadelphia, July 24-26. Brent Yorgey [23]announced Hac phi, a Haskell hackathon/get-together to be held July 24-26 at the University of Pennsylvania in Philadelphia. The hackathon will officially kick off at 2:30 Friday afternoon, and go until 5pm on Sunday (with breaks for sleep, of course). Everyone is welcome---you do not have to be a Haskell guru to attend! Helping hack on someone else's project could be a great way to increase your Haskell-fu. If you plan on coming, please [24]register. There is a block of hotel rooms available at a special rate only until June 15, so register early! More details can be found on the [25]Hac phi wiki. Job for someone: make a VM image for GHC development. Simon Marlow [26]suggested a useful project for someone looking for something to do: create a VM image of a Linux system with a complete GHC development environment set up and ready to go. My attempt at Haskell USB. Mauricio [27]announced some [28]Haskell bindings to libusb, and gave another plug for his [29]bindings-common package, which makes it easier to generate Haskell bindings to low-level libraries. second alpha release of OSX haskell platform installer. Gregory Collins [30]announced a [31]second candidate release for the OSX Haskell Platform installer. Please try it out! Release Schedule for 2009.2.0.2. Don Stewart [32]announced the [33]release schedule for the next minor release of the 2009.2.0 branch of the Haskell Platform. The freeze for package changes will be Wednesday 1 July, and the release is scheduled for Monday 13th July. hscamwire, for IIDC1394 cameras. Frederick Ross [34]announced the release of [35]hscamwire 0.1, which provides a nice Haskellized layer over Camwire, a library to connect to IIDC1394 cameras (most scientific and industrial Firewire cameras) on Linux. Safe and generic printf with C-like format string. oleg [36]announced some code to implement a type-safe polyvariadic version of printf, which is also integrated with Show so that any showable type can be printed. A library for serial ports. Frederick Ross [37]announced the release of [38]serial-0.1, a library for line-oriented interaction with serial ports on POSIX compatible systems. HaL4: Haskell-Meeting in Germany, 12th June 2009. Janis Voigtlaender [39]reminded everyone of [40]Hal4, a German-language Haskell gathering to be held in Halle/Saale on June 12. There are already close to 50 registered participants, so expect a very lively meeting! Late registration still possible. wp-archivebot 0.1 - archive Wikipedia's external links in WebCite. Gwern Branwen [41]announced [42]wp-archivebot, a relatively simple little script which follows all the links in a RSS feed, combs the destination for http:// links, and submits them to [43]WebCite. memscript-0.0.0.2. Ki Yung Ahn [44]announced [45]memscript, a command line utility for memorizing scriptures or any other text. HSH 2.0.0. John Goerzen [46]announced the release of [47]version 2.0.0 of HSH, the Haskell shell scripting library. This version features a complete rewrite of the core using System.Process, a drastic reduction in code size and complexity, cross-platform support, and a simpler and more flexible API. atom-0.0.5. Tom Hawkins [48]announced version 0.5 of the [49]atom library, a DSL for embedded hard realtime applications. This version includes a few bug fixes and doc improvements. heap-1.0.0. Stephan Friedrichs [50]announced a rewrite of the heap package, [51]heap-1.0.0. It is not 100% compatible with version 0.6.0, but provides major improvements, including a better mechanism for instantiating min-, max-, min-prio- and max-prio-heaps, and faster {from,to}{Asc,Desc}List conversions. The Haskell Platform 2009.2.0.1. Don Stewart [52]announced the second release (2009.2.0.1) of the [53]Haskell Platform, a single, standard Haskell distribution for everyone. The specification, along with installers (including Windows and Unix installers for a full Haskell environment) are available. Anglohaskell 2009. Philippa Cowderoy [54]announced [55]Anglohaskell 2009, to be held at MSR Cambridge on the 7th and 8th of August. code reviewers wanted for hashed-storage (darcs). Eric Kow [56]solicited anyone with a few spare hours this summer willing to help the Darcs project as a code reviewer for the standalone hashed-storage module, which will be used by Darcs in the future. No Darcs experience is needed! Google Summer of Code Progress updates from participants in the 2008 [57]Google Summer of Code. Haddock improvements. Isaac Dupree has begun looking at the Haddock code, and has a [58]question about which of two options he should pursue. EclipseFP. Thomas Ten Cate has posted an [59]explanation of how the Scion client/server model works. Space profiling. Gergely Patai has [60]uploaded a preliminary version of the [61]hp2any core library which handles heap profiles both during and after execution. He has also [62]posted some pretty graphs generated by a simple utility built on top of the core library. haskell-src-exts. Niklas Broberg has begun work by making a [63]list of all language extensions and the ways in which they affect lexing and parsing, since haskell-src-exts will need to be parameterized over these extensions. Fast Darcs. Petr Rockai has posted two detailed [64]progress [65]reports already, with many changes to both the standalone [66]hashed-storage library and a [67]fork of darcs which uses it. Discussion Error message reform (was: Strange type error with associated type synonyms). Max Rabkin began an interesting [68]discussion about error messages. Do you have an intuitive sense of which is the 'expected' and which the 'inferred' type? time library dependencies. Ashley Yakeley [69]asked what dependencies are acceptable for the time library, leading to a discussion of what dependencies are acceptable for base packages. Bool as type class to serve EDSLs. Sebastiaan Visser started a [70]discussion on the possibility of a type class for representing Boolean values, much like the current Num class for numeric values. Jobs 10 jobs in declarative programming. Oege de Moor [71]announced the availability of positions with Semmle and LogicBlox for ten declarative programming consultants, who will work with clients to write custom queries in Datalog, and to create user interfaces in a declarative framework. Semmle and LogicBlox are creating a platform for declarative programming in Datalog, a pure logic programming language. Semmle is based in Oxford, headed by Oege de Moor; LogicBlox is based in Atlanta, headed by Molham Aref. See the announcement for more information and how to apply. Blog noise [72]Haskell news from the [73]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * David Amos: [74]Welcome to Haskell for Maths. David's Haskell library for mathematics exploration is under development again! * Joachim Breitner: [75]Third place in AI programming contest. * Bryan O'Sullivan: [76]Dealing with encoding errors in Data.Text. * Remco Niemeijer: [77]Programming Praxis - Ternary Search Tries. * beelsebob: [78]Collecting Non-Memory Resources. * Luke Palmer: [79]It is never safe to cheat. Ceiling cat is watching you. * Alex McLean: [80]More hackery. More cool livecoding with Haskell. * Thomas ten Cate: [81]Client/server communication. * Gergely Patai: [82]The first graphs. * Alson Kemp: [83]Turbinado V0.6.5. * Don Stewart (dons): [84]The Haskell Platform 2009.2.0.1. The first minor update release of the Haskell Platform is here. * Alson Kemp: [85]Turbinado V0.6.5. * Michael Snoyman: [86]Functors and Monads (containers). * Well-Typed.Com: [87]Come talk at the Haskell Implementers' Workshop!. * GSoC Fast Darcs: [88]soc progress 2. * Shin-Cheng Mu: [89]On a Basic Property for the Longest Prefix Problem. * >>> Ben Hutchison: [90]OO/Imperative programmers: 'Study Functional Programming or Be Ignorant'. * Michael Snoyman: [91]Run a MonadCGI as a CGI application!. * Michael Snoyman: [92]Wordify: RESTful Haskell web apps. * Marco Tulio Gontijo e Silva: [93]xmlGetWidget without castTo*. * >>> slawekk: [94]Probability monad. * Brandon Simmons: [95]Huffman Coding. * Niklas Broberg: [96]Parametrising haskell-src-exts on extensions. A list of language extensions and how they affect parsing. * Manuel M T Chakravarty: [97]Instant Generics now has a website!. * GHC / OpenSPARC Project: [98]The CAS experiment. * Brent Yorgey: [99]Hac phi!. Registration is now open. * Jeff Heard: [100]Buster 2.2 - Application Orchestration redux. Example code showing off Buster. * Bryan O'Sullivan: [101]I put a pidgit in your widget so you can fidget while you calculate pi. GHC and the language shootout. * Niklas Broberg: [102]Haskell Platform, I'm in love. * Bjorn Buckwalter: [103]Benchmarking Amazon EC2 with GHC. * Bjorn Buckwalter: [104]Blogging with Pandoc, literate Haskell, and a bug. * >>> Chris Moos: [105]Haskell AIM Client - a cool proof of concept. * Marco Tulio Gontijo e Silva: [106]Generating code with Haskell-src and TH. Quotes of the Week * pumpkin: we should throw it [CReal] in with Foreign.C.Types to confuse people * MyCatVerbs: The *real* best way to optimize a program is to tell dons that it's been added to the Shootout. * SimonFrankau: The points-free approach, while elegant, can make code unreadable, especially if it is written by quantitative analysts moonlighting as functional programmers. * ValarQ: l33t_h4x0r: could you help me port GHC to the AVR architecture? <-- l33t_h4x0r has left #haskell * gwern: drat. what *do* all you people talk about? only one bacon and one zombie quote * quicksilver: well if you can get proggit to help with your interview, then perhaps you can get proggit to help with the job when you get it. So it's not cheating, it's just an indication of one of your skill sets. * shapr: I haven't tried F#, everytime I get the urge to do something fun with .NET I have SharePoint flashbacks and buy more hardware instead. * gwern: bleh. haskell is messing me up. I wondered what operator =) is, before I realized it was a syntax error, before I realized it was an emoticon About the Haskell Weekly News New editions are posted to [107]the Haskell mailing list as well as to [108]the Haskell Sequence and [109]Planet Haskell. [110]RSS is also available, and headlines appear on [111]haskell.org. To help create new editions of this newsletter, please see the information on [112]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [113]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://haskell.org/haskellwiki/Hac_%CF%86 3. http://article.gmane.org/gmane.comp.lang.haskell.general/17225 4. http://article.gmane.org/gmane.comp.lang.haskell.general/17214 5. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/storable-record 6. http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ 7. http://article.gmane.org/gmane.comp.lang.haskell.general/17208 8. http://www.haskell.org/communities/ 9. http://www.haskell.org//pipermail/haskell-cafe/2009-May/061841.html 10. http://hledger.org/ 11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58955 12. http://code.haskell.org/haskell-src-exts 13. http://trac.haskell.org/haskell-src-exts 14. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58928 15. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bsd-sysctl 16. http://www.haskell.org//pipermail/haskell-cafe/2009-May/061887.html 17. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multirec-binary 18. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multirec 19. http://www.haskell.org//pipermail/haskell-cafe/2009-June/062297.html 20. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59268 21. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59256 22. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uu%2Dparsinglib 23. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59156 24. http://haskell.org/haskellwiki/Hac_%CF%86/Register 25. http://haskell.org/haskellwiki/Hac_%CF%86 26. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/17046 27. http://article.gmane.org/gmane.comp.lang.haskell.libraries/11243 28. http://hackage.haskell.org/packages/archive/bindings-libusb/0.0.3/doc/html/Bindings-Libusb.html 29. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bindings-common-0.1.3 30. http://article.gmane.org/gmane.comp.lang.haskell.libraries/11224 31. http://gregorycollins.net/static/haskell/haskell-platform-2009.2.0.1-alpha2.pkg 32. http://article.gmane.org/gmane.comp.lang.haskell.libraries/11217 33. http://trac.haskell.org/haskell-platform/wiki/ReleaseTimetable 34. http://article.gmane.org/gmane.comp.lang.haskell.general/17253 35. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hscamwire 36. http://article.gmane.org/gmane.comp.lang.haskell.general/17251 37. http://article.gmane.org/gmane.comp.lang.haskell.general/17247 38. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/serial 39. http://article.gmane.org/gmane.comp.lang.haskell.general/17238 40. http://iba-cg.de/hal4.html 41. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59435 42. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wp%2Darchivebot 43. https://secure.wikimedia.org/wikipedia/en/wiki/WebCite 44. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59415 45. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/memscript 46. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59405 47. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HSH 48. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59400 49. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/atom 50. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59363 51. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/heap 52. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59338 53. http://hackage.haskell.org/platform/ 54. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59337 55. http://www.haskell.org/haskellwiki/AngloHaskell/2009 56. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59327 57. http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2008 58. http://haddock2009.wordpress.com/2009/05/26/another-boring-update-question/ 59. http://eclipsefp.wordpress.com/2009/06/03/clientserver-communication/ 60. http://just-bottom.blogspot.com/2009/05/read-your-profiles.html 61. http://code.google.com/p/hp2any/ 62. http://just-bottom.blogspot.com/2009/06/first-graphs.html 63. http://nibrofun.blogspot.com/2009/05/parametrising-haskell-src-exts-on.html 64. http://web.mornfall.net/blog/soc_progress_1.html 65. http://web.mornfall.net/blog/soc_progress_2.html 66. http://repos.mornfall.net/hashed-storage 67. http://repos.mornfall.net/darcs/darcs-hs 68. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/59073 69. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/11163 70. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/59021 71. http://article.gmane.org/gmane.comp.lang.haskell.general/17207 72. http://planet.haskell.org/ 73. http://haskell.org/haskellwiki/Blog_articles 74. http://haskellformaths.blogspot.com/2009/06/welcome-to-haskell-for-maths.html 75. https://www.joachim-breitner.de/blog/archives/328-Third-place-in-AI-programming-contest.html 76. http://www.serpentine.com/blog/2009/06/05/dealing-with-encoding-errors-in-datatext/ 77. http://bonsaicode.wordpress.com/2009/06/05/programming-praxis-ternary-search-tries/ 78. http://noordering.wordpress.com/2009/06/05/collecting-non-memory-resources/ 79. http://lukepalmer.wordpress.com/2009/06/04/it-is-never-safe-to-cheat/ 80. http://yaxu.org/more-hackery/ 81. http://eclipsefp.wordpress.com/2009/06/03/clientserver-communication/ 82. http://just-bottom.blogspot.com/2009/06/first-graphs.html 83. http://www.alsonkemp.com/haskell/turbinado-v065/ 84. http://donsbot.wordpress.com/2009/06/02/the-haskell-platform-2009-2-0-1/ 85. http://www.alsonkemp.com/haskell/turbinado-v065/ 86. http://blog.snoyman.com/2009/06/02/functors-and-monads-containers/ 87. http://blog.well-typed.com/2009/06/come-talk-at-the-haskell-implementers-workshop/ 88. http://web.mornfall.net/blog/soc_progress_2.html 89. http://www.iis.sinica.edu.tw/~scm/2009/on-a-basic-property-for-the-longest-prefix-problem/ 90. http://benhutchison.wordpress.com/2009/06/02/study-functional-programming-or-be-ignorant/ 91. http://blog.snoyman.com/2009/05/20/run-a-monadcgi-as-a-cgi-application/ 92. http://blog.snoyman.com/2009/05/20/wordify-restful-haskell-web-apps/ 93. http://marcot.iaaeee.org/diario/?p=137 94. http://slawekk.wordpress.com/2009/05/31/probability-monad/ 95. http://coder.bsimmons.name/blog/2009/05/huffman-coding/ 96. http://nibrofun.blogspot.com/2009/05/parametrising-haskell-src-exts-on.html 97. http://justtesting.org/post/115191589 98. http://ghcsparc.blogspot.com/2009/05/cas-experiment.html 99. http://byorgey.wordpress.com/2009/05/28/hac-%cf%86/ 100. http://vis.renci.org/jeff/2009/05/28/buster-22-application-orchestration-redux/ 101. http://www.serpentine.com/blog/2009/05/27/i-put-a-pidgit-in-your-widget-so-you-can-fidget-while-you-calculate-pi/ 102. http://nibrofun.blogspot.com/2009/05/haskell-platform-im-in-love.html 103. http://flygdynamikern.blogspot.com/2009/05/benchmarking-amazon-ec2-with-ghc.html 104. http://flygdynamikern.blogspot.com/2009/03/blogging-with-pandoc-literate-haskell.html 105. http://chrismoos.com/2009/05/26/haskell-aim-client-a-cool-proof-of-concept/ 106. http://marcot.iaaeee.org/diario/?p=130 107. http://www.haskell.org/mailman/listinfo/haskell 108. http://sequence.complete.org/ 109. http://planet.haskell.org/ 110. http://sequence.complete.org/node/feed 111. http://haskell.org/ 112. http://haskell.org/haskellwiki/HWN 113. http://code.haskell.org/~byorgey/code/hwn/ From bjorn.buckwalter at gmail.com Sat Jun 6 17:51:10 2009 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Sat Jun 6 17:35:22 2009 Subject: [Haskell] ANNOUNCE: numtype 1.0 -- Type-level (low cardinality) integers Message-ID: <8b2a1a960906061451s2a5adf61k64579161c7041d@mail.gmail.com> Dear all, Since its inception my dimensional library has been built around a unary type-level representation of integers (NumTypes) defined in the Numeric.NumType module. This module has proven itself useful outside the context of dimensional and after dragging my feet for a long time I've finally gotten around packaging it up in its own library: numtype[1]. The Numeric.NumType module is completely self-contained (only imports Prelude) and is heavily commented in a narrative manner inspired by Oleg Kiselyov's expositions. I believe it provides a good case study for type-level programming with multi-parameter type classes and functional dependencies. Addition, subtraction, division, and multiplication of NumTypes is supported. NumTypes have no value-level representation but can be converted to any Num instance with the 'toNum' function. The numtype library has two significant short-comings: * Minimal haddocks -- as with my dimensional library the literate Haskell source code is the documentation. The flip-side is that the code is very well-commented. * Due to the unary implementation the practical size of the NumTypes is severely limited, making them unsuitable for large-cardinality applications. If you will be working with integers beyond (-20, 20) this package probably isn't for you. (If the second bullet is a show-stopper Edward Kmett's type-int[2] library may be a better choice. Peter Gavin's tfp[3] library also provides type-level integers but uses type families instead of MPTCs and fundeps. I cannot vouch for either of these libraries as I haven't used them.) Numtype version 1.0 can be downloaded from Hackage or the dimensional project page[4]. I've also updated dimensional to version 0.8 with the Numeric.NumType module removed and Julian 'year' and 'century' units added. Enjoy! Thanks, Bjorn Buckwalter [1]: http://code.google.com/p/dimensional/wiki/numtype [2]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/type-int [3]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/tfp [4]: http://dimensional.googlecode.com From madhadron at gmail.com Mon Jun 8 04:57:17 2009 From: madhadron at gmail.com (Frederick Ross) Date: Mon Jun 8 04:40:59 2009 Subject: [Haskell] serial-0.2 Message-ID: serial is a library for working with line-oriented POSIX serial ports. The changes from 0.1 are: * Added a BlockingSerialManager for those devices which have completely ambiguous responses and can't be sorted out nicely to send back to calling functions. Instead, it executes commands one after another, waits until they are done, sends the response back, and moves on to the next command. The magic of MVars makes all this line up properly. * Switched SerialManager to use predicates (String -> Bool) instead of Parsec parsers for sorting out return values. * Turned on -Wall and dealt with everything that appeared. * Decided to use LGPL instead of GPL, at least for now. -- Frederick Ross Doctorant, SV/GHI/UPKIN, EPFL Graduate Fellow, The Rockefeller University From tux_rocker at reinier.de Mon Jun 8 06:24:23 2009 From: tux_rocker at reinier.de (Reinier Lamers) Date: Mon Jun 8 06:08:24 2009 Subject: [Haskell] ANNOUNCE: testrunner-0.9 Message-ID: <200906081224.36779.tux_rocker@reinier.de> Dear all, testrunner is a new framework to run unit tests. It has the following distinguishing features: * It can run unit tests in parallel. * It can run QuickCheck and HUnit tests as well as simple boolean expressions. * It comes with a ready-made main function for your unit test executable. * This main function recognizes command-line arguments to select tests by name and replay QuickCheck tests. testrunner was conceived as a part of the darcs project. The home page is http://projects.haskell.org/testrunner/. testrunner can be downloaded from http://projects.haskell.org/testrunner/releases/testrunner-0.9.tar.gz, or with darcs with a "darcs get http://code.haskell.org/testrunner/". Regards, Reinier Lamers (tux_rocker) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/haskell/attachments/20090608/fec456bd/attachment.bin From batterseapower at hotmail.com Mon Jun 8 09:03:54 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Jun 8 08:47:40 2009 Subject: [Haskell] ANNOUNCE: testrunner-0.9 In-Reply-To: <200906081224.36779.tux_rocker@reinier.de> References: <200906081224.36779.tux_rocker@reinier.de> Message-ID: <9d4d38820906080603x9acf62dm32474012c451981a@mail.gmail.com> Your feature list sounds like an almost exact duplicate of that for my test-framework package, which has been available on Hackage for months (although it's almost totally unadvertised!): https://github.com/batterseapower/test-framework/tree http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework There is also John's testpack: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/testpack Seems like we need to advertise these better :-) Cheers, Max 2009/6/8 Reinier Lamers : > Dear all, > > testrunner is a new framework to run unit tests. It has the following > distinguishing features: > > * It can run unit tests in parallel. > * It can run QuickCheck and HUnit tests as well as simple boolean expressions. > * It comes with a ready-made main function for your unit test executable. > * This main function recognizes command-line arguments to select tests by name > ?and replay QuickCheck tests. > > testrunner was conceived as a part of the darcs project. > > The home page is http://projects.haskell.org/testrunner/. > > testrunner can be downloaded from > http://projects.haskell.org/testrunner/releases/testrunner-0.9.tar.gz, or with > darcs with a "darcs get http://code.haskell.org/testrunner/". > > Regards, > Reinier Lamers (tux_rocker) > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > From amf at ncc.up.pt Mon Jun 8 11:37:06 2009 From: amf at ncc.up.pt (=?UTF-8?B?TcKHw6FyaW8gRmxvcmlkbw==?=) Date: Mon Jun 8 11:17:50 2009 Subject: [Haskell] LINEARITY 2009 - Call for Papers Message-ID: <4A2D3022.4000207@ncc.up.pt> Call for Papers LINEARITY 2009 First International Workshop on Linearity http://www.lix.polytechnique.fr/linearity/ Coimbra, Portugal 12 September 2009 A satellite event of CSL 2009, 18th EACSL Annual Conference on Computer Science Logic =================================================================== Important Dates --------------- * 5 July 2009: Abstract deadline * 10 July 2009: Submission deadline * 24 July 2009: Author notification * 1 September 2009: Deadline for final versions of accepted papers * 12 September 2009: Workshop The pre-proceedings and program will be online here before the workshop. Scope ----- Linearity has been the key feature in several lines of research in both theoretical and practical approaches to computer science. In the theoretical side all the work stemming from linear logic dealing with proof technology, complexity classes and more recently quantum computation. In the practical side work on program analysis, expressive operational semantics for programming languages, linear programming languages, program transformation, update analysis and efficient implementation techniques. The aim of this workshop is to bring together researchers who are currently developing theory and applications of linear calculi, in order to foster their interaction, to provide a forum for presenting new ideas and work in progress, and to enable newcomers to learn about current activities in this area. LINEARITY 2009 will be a one-day satellite event of CSL 2009. Topics ------ Topics of interest include foundational calculus, models, applications to programming languages and systems. This includes (but is not limited to): * Linear types: session types, etc * Linear calculi; * Functional calculi: lambda-calculus, rho-calculus, term and graph rewriting; * Object calculi; * Interaction-based systems: interaction nets, games; * Concurrent models: process calculi, action graphs; * Calculi expressing locality, mobility, and active data; * Quantum computational models; * Biological or chemical models of computation; Submission and Publication -------------------------- Authors are invited to submit a short paper (5-7 pages) by 10 July 2009. Preliminary proceedings will be available at the workshop. Papers should be written in English, and submitted in PostScript or PDF format, using the EPTCS style files. Submission is through the Easychair website: http://www.easychair.org/conferences/?conf=linearity2009 After the workshop authors are invited to submit a revised version (12 pages) of their presentation. Accepted contributions will appear in an electronic proceedings Authors and participants will also be invited to submit an article to a special issue of the Journal of Logic and Computation. Programme Committee * Sandra Alves * Ugo Dal Lago * Maribel Fernandez * Simon Gay * Mario Florido (co-chair) * Martin Hofmann * Ian Mackie (co-chair) * Greg Morrisett * Alan Mycroft * Luke Ong * Luca Paolini Contact ------- linearity@lix.polytechnique.fr From sebf at informatik.uni-kiel.de Mon Jun 8 12:41:48 2009 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Mon Jun 8 12:25:34 2009 Subject: [Haskell] purely functional lazy non-deterministic programming References: Message-ID: [crosspost from Haskell-libraries and Curry mailing list] Dear Haskell and Curry programmers, there is now a Haskell library that supports lazy functional-logic programming in Haskell. It is available from http://sebfisch.github.com/explicit-sharing and can be obtained from Hackage using cabal-install. The project page links to tutorials that explain how to use the library and to an ICFP'09 paper (joint work with Oleg Kiselyov and Chung-chieh Shan) that explains the implemented ideas in depth. Have fun! Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) From jwlato at gmail.com Tue Jun 9 07:09:50 2009 From: jwlato at gmail.com (John Lato) Date: Tue Jun 9 06:53:30 2009 Subject: [Haskell] ANN: iteratee-0.2.1 released Message-ID: <9979e72e0906090409j5e7b8170i2a69d18dfcf2d5e5@mail.gmail.com> Hello, I would like to announce the release of iteratee-0.2.1, a major update to the iteratee library. This library provides types and functions for performing enumerator/iteratee based I/O operations in Haskell, as described by Oleg at http://okmij.org/ftp/Streams.html#iteratee. This library is intended to be used for incremental, strict I/O and provides high performance and composability. The 0.2 version is a large redesign from the initial release, with many breaking changes. A major new feature is support for resumable exceptions. The interface has been greatly simplified, including the following: -Iteratees that previously returned a result of "Maybe a" will now usually have a result of "a", making it much simpler to combine multiple iteratees. The "bindm" combinator is no longer necessary. Failed operations should now result in a resumable exception. User-defined iteratees may still have results of "Maybe a" of course. -The types IterateeG and IterateeGM have been unified; IterateeGM is no longer necessary or supplied. -The combinators (>>==) and (==<<) are no longer necessary or supplied; the same functionality is provided by (>>=) and ($). -The new combinator "joinIM" simplifies composing multiple enumerations in certain monadic contexts. -The StreamChunk class now depends upon Monoid and ListLike, and defaults are provided for all functions, simplifying the work necessary to create a new StreamChunk instance (although performance can be greatly improved by providing certain custom implementations). -The library depends upon transformers instead of mtl for monadic composition. I made this change because it looks like mtl will be deprecated from HPC in the near future, however it could be reverted if necessary. The only difference between 0.2 and 0.2.1 is that I removed a section on building the test executable from the .cabal file so that test frameworks wouldn't be required of all users. All necessary files for testing are supplied with 0.2.1, they just have to be built manually. The process of updating earlier code to work with this version can be more-or-less straightforward, depending upon style and the particular functionality accessed. I would be happy to provide assistance if anyone is in this situation. Thanks to the following individuals for contributing code to this release: Oleg Kiselyov Bas van Dijk Paulo Tanimoto Thanks to Johan Tibell for comments and ongoing support. Cheers, John Lato From madhadron at gmail.com Tue Jun 9 11:04:38 2009 From: madhadron at gmail.com (Frederick Ross) Date: Tue Jun 9 10:48:16 2009 Subject: [Haskell] pgm-0.1 on Hackage Message-ID: pgm is a pure Haskell library to read and write PGM images. Points of note: * Seamlessly handles the divide between 1 and 2 byte per pixel images (this is vital for folks doing microscopy, since otherwise we're stuck in tiff hell). * Returns the images as UArrays; writes from UArrays. * Handles multiple PGMs concatenated one after another in a file, provided they are separated only by (optional) whitespace. * Encodes and decodes all comments in the PGM header, which can be used to drop arbitrary metadata into files in a human readable manner. -- Frederick Ross Doctorant, SV/GHI/UPKIN, EPFL Graduate Fellow, The Rockefeller University From dons at galois.com Thu Jun 11 03:15:41 2009 From: dons at galois.com (Don Stewart) Date: Thu Jun 11 03:01:00 2009 Subject: [Haskell] ANNOUNCE: Galois is hiring functional programmers Message-ID: <20090611071541.GA12524@whirlpool.galois.com> Galois is hiring. Bringing together mathematicians, researchers and technologists, Galois, based in Portland, Oregon, was founded in 1999 with the mission to apply functional languages and formal methods to solve real world problems. Today, over 30 members strong, we?re living the vision, 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. Members work on one or more projects, and are expected to perform in a variety of roles based upon their talents and organizational needs. 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. Galois technical staff members usually work in a small team setting (2-5 members), and must successfully interact with clients, partners, and other employees in a highly cooperative, collaborative, and intellectually challenging environment. A Masters or Ph.D. degree in Computer Science is desirable but not required. Additionally, a strong programming background and experience with Haskell or other functional programming languages is preferred but not required. 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@galois.com. From Sven.Panne at aedion.de Thu Jun 11 12:56:01 2009 From: Sven.Panne at aedion.de (Sven Panne) Date: Thu Jun 11 12:39:40 2009 Subject: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0 Message-ID: <200906111856.01646.Sven.Panne@aedion.de> As a first step to make the OpenGL package easier to install, more modular and a bit more flexible, a low-level binding for OpenGL has been uploaded to Hackage. From OpenGLRaw's package description: ------------------------------------------------------------ OpenGLRaw is a raw Haskell binding for the OpenGL 3.1 graphics system and lots of OpenGL extensions. It is basically a 1:1 mapping of OpenGL's C API, intended as a basis for a nicer interface. OpenGLRaw offers access to all necessary functions, tokens and types plus a general facility for loading extension entries. The module hierarchy closely mirrors the naming structure of the OpenGL extensions, making it easy to find the right module to import. All API entries are loaded dynamically, so no special C header files are needed for building this package. If an API entry is not found at runtime, a userError is thrown. OpenGL is the industry's most widely used and supported 2D and 3D graphics application programming interface (API), incorporating a broad set of rendering, texture mapping, special effects, and other powerful visualization functions. For more information about OpenGL and its various extensions, please see http://www.opengl.org/ and http://www.opengl.org/registry/. ------------------------------------------------------------ Version 1.0.0.0 covers the OpenGL 3.1 core, all ARB extensions and all EXT extensions. Great care has been taken to introduce as few build dependencies as possible, so neither autoconf is required, nor any OpenGL headers. Future versions of the OpenGL package will basically be a convenience layer above this package, but you can always fall back to the raw binding if required. To get a taste for it, have a look at http://aedion.de/haskell/SmoothRaw.hs, which should look extremely familiar to anyone who has used OpenGL's C API. Any feedback is highly appreciated. Cheers, S. From bos at serpentine.com Thu Jun 11 13:23:17 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Jun 11 13:06:51 2009 Subject: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0 In-Reply-To: <200906111856.01646.Sven.Panne@aedion.de> References: <200906111856.01646.Sven.Panne@aedion.de> Message-ID: On Thu, Jun 11, 2009 at 9:56 AM, Sven Panne wrote: > > Any feedback is highly appreciated. > Since this is a new package, is there any possibility that the naming could be more economical? Graphics.Rendering.OpenGL.GL.CoordTrans is awfully long. I think that "Graphics.Rendering." is clutter, and "OpenGL.GL." seems redundant to me. I'd very much like to encourage the idea that tremendously long package names ought to be considered poor form. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090611/7d415a8f/attachment.html From kahl at cas.mcmaster.ca Thu Jun 11 14:41:11 2009 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Thu Jun 11 14:24:48 2009 Subject: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0 In-Reply-To: (bos@serpentine.com) References: <200906111856.01646.Sven.Panne@aedion.de> Message-ID: <20090611184111.17119.qmail@schroeder.cas.mcmaster.ca> > > Graphics.Rendering.OpenGL.GL.CoordTrans is awfully long. > > I think that "Graphics.Rendering." is clutter, and "OpenGL.GL." seems > redundant to me. I'd very much like to encourage the idea that tremendously > long package names ought to be considered poor form. ... or be made abstractable, e.g.: import prefix Graphics.Rendering.OpenGL.GL as OpenGL import OpenGL.CoordTrans Wolfram From Sven.Panne at aedion.de Fri Jun 12 05:24:19 2009 From: Sven.Panne at aedion.de (Sven Panne) Date: Fri Jun 12 05:07:52 2009 Subject: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0 In-Reply-To: References: <200906111856.01646.Sven.Panne@aedion.de> Message-ID: <200906121124.19484.Sven.Panne@aedion.de> Am Donnerstag, 11. Juni 2009 19:23:17 schrieb Bryan O'Sullivan: > Since this is a new package, is there any possibility that the naming could > be more economical? > > Graphics.Rendering.OpenGL.GL.CoordTrans is awfully long. > > I think that "Graphics.Rendering." is clutter, and "OpenGL.GL." seems > redundant to me. I'd very much like to encourage the idea that tremendously > long package names ought to be considered poor form. While I consider this a bit long, too, there are a few reasons why it was done this way. The OpenGLRaw package exports 1025 functions, 1673 tokens and 20 types, so one clearly needs some way of structuring this, the only question is how. You rarely import on such a fine-grained level, most of the time you simply use the rather short import Graphics.Rendering.OpenGL import, where you can even add "as GL" if you like for short explicit qualification later. Another example: If you explicitly only want to use pure, modern OpenGL 3.1 "the raw way", use: import Graphics.Rendering.OpenGL.Raw.Core31 If you additionally want to use the ARB_compatibility extension, use: import Graphics.Rendering.OpenGL.Raw.Core31 import Graphics.Rendering.OpenGL.Raw.ARB.Compatibility If you want the OpenGL 3.1 core plus all ARB extensions, use import Graphics.Rendering.OpenGL.Raw.Core31 import Graphics.Rendering.OpenGL.Raw.ARB And if you are very lazy, you can simply pull in the whole raw binding with import Graphics.Rendering.OpenGL.Raw This leaves the decision about the granularity of the import to the user of the package, which is a good thing IMHO. The ".Raw" part is necessary to distinguish between the raw and the nice interface, leaving the dot out or replacing it with "_" wouldn't really buy us much. One point here is debatable: Do we really need the ".Rendering" part in the package name or would simply "Graphics.OpenGL.Raw" be enough? We discussed the structure of the hierarchy when hierarchical packages were in their infancy, many years ago, and it was consensus then to distinguish between "Graphics.Rendering" and "Graphics.UI". I don't have very strong feelings about ".Rendering" and ".UI", and if the consensus nowadays is to remove it, I'll be happy to change this. But let's move the discussion about this to the libraries mailing list. A few final remarks: Leaving out "Graphics." completely would be a very bad idea, the naming hierarchy should reflect the underlying conceptual hierarchy. The only problem with hierarchies in general is that sometimes the position in it is not very clear. I have e.g. never fully understood why "Monad" and "Applicative" are below "Control", but "Foldable" is below "Data"... Cheers, S. From Sven.Panne at aedion.de Fri Jun 12 06:32:19 2009 From: Sven.Panne at aedion.de (Sven Panne) Date: Fri Jun 12 06:15:52 2009 Subject: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0 In-Reply-To: References: <200906111856.01646.Sven.Panne@aedion.de> Message-ID: <200906121232.20132.Sven.Panne@aedion.de> Am Donnerstag, 11. Juni 2009 19:23:17 schrieb Bryan O'Sullivan: > [...] I think that "Graphics.Rendering." is clutter, and "OpenGL.GL." seems > redundant to me. [...] I forgot to mention one thing here: "OpenGL.GL" is currently *not* redundant, there is "OpenGL.GLU" in the OpenGL package, too. GL and GLU are separate libraries, even living in separate DLLs/*.sos, having separate headers, etc., so they should be kept separate in Haskell at some level, too. Nevertheless, with OpenGL 3.1 GLU is dead, anyway, so in future versions there will be no ".GL" part in the package names. Cheers, S. From ppk at cse.iitk.ac.in Fri Jun 12 11:22:37 2009 From: ppk at cse.iitk.ac.in (Piyush P Kurur) Date: Fri Jun 12 11:06:21 2009 Subject: [Haskell] FSTTCS 2009 Call for papers Message-ID: <20090612152237.GA10211@cse.iitk.ac.in> Hi, The deadline for FST TCS 2009 is nearing (July 7 2009). Please do send your interesting results via easychair http://www.easychair.org/conferences/?conf=fsttcs2009 Details: http://www.fsttcs.org/ Hope to see you in Kanpur Regards ppk From uzytkownik2 at gmail.com Sat Jun 13 10:39:45 2009 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Sat Jun 13 10:23:15 2009 Subject: [Haskell] ANNOUNCE: nntp 0.0.1 Message-ID: <1244903985.2932.35.camel@notebook.piechotka.com.pl> Nntp is a library to connect to nntp (i.e. mainly USENET) servers. Currently RFC977 is being implemented. It is published on the LGPL v3 license. Currently implemented: Currently all commands from RFC are implemented. However for user interaction other, more generic interface is provided. Currently tested: Automated testing is not available yet. Tested is only *small* subset of commands and it is at an early stage of development. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell/attachments/20090613/6e7d56d2/attachment.bin From uzytkownik2 at gmail.com Sat Jun 13 10:42:04 2009 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Sat Jun 13 10:25:33 2009 Subject: [Haskell] Re: ANNOUNCE: nntp 0.0.1 In-Reply-To: <1244903985.2932.35.camel@notebook.piechotka.com.pl> References: <1244903985.2932.35.camel@notebook.piechotka.com.pl> Message-ID: <1244904124.2932.37.camel@notebook.piechotka.com.pl> On Sat, 2009-06-13 at 16:39 +0200, Maciej Piechotka wrote: > Nntp is a library to connect to nntp (i.e. mainly USENET) servers. > Currently RFC977 is being implemented. It is published on the LGPL v3 > license. > > Currently implemented: Currently all commands from RFC are implemented. > However for user interaction other, more generic interface is provided. > > Currently tested: Automated testing is not available yet. Tested is only > *small* subset of commands and it is at an early stage of development. > Ups. I forgot to add the most important part - the link: http://hackage.haskell.org/package/nntp-0.0.1 Regards -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell/attachments/20090613/218dc33c/attachment.bin From dot at dotat.at Sat Jun 13 11:38:16 2009 From: dot at dotat.at (Tony Finch) Date: Sat Jun 13 11:21:43 2009 Subject: [Haskell] ANNOUNCE: nntp 0.0.1 In-Reply-To: <1244903985.2932.35.camel@notebook.piechotka.com.pl> References: <1244903985.2932.35.camel@notebook.piechotka.com.pl> Message-ID: On Sat, 13 Jun 2009, Maciej Piechotka wrote: > Nntp is a library to connect to nntp (i.e. mainly USENET) servers. > Currently RFC977 is being implemented. You should be referring to RFC 3977, published in October 2006. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From uzytkownik2 at gmail.com Sat Jun 13 13:09:33 2009 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Sat Jun 13 12:53:02 2009 Subject: [Haskell] ANNOUNCE: nntp 0.0.1 In-Reply-To: References: <1244903985.2932.35.camel@notebook.piechotka.com.pl> Message-ID: <1244912973.10833.49.camel@notebook.piechotka.com.pl> On Sat, 2009-06-13 at 16:38 +0100, Tony Finch wrote: > On Sat, 13 Jun 2009, Maciej Piechotka wrote: > > > Nntp is a library to connect to nntp (i.e. mainly USENET) servers. > > Currently RFC977 is being implemented. > > You should be referring to RFC 3977, published in October 2006. > > Tony. Thank you very much for responding. I'm perfectly aware of RFC 3977. However I don't know a server which implemented CAPABILITIES. Therefore I would no idea how to test it in wild - and servers I have access to have relatively good cover of RFC 977. As the subset of commands is very similar I thought about lifting the 977 into 2980, 3977, 4643... Each of this module may fallback to the 'safer' implementation in terms of older standard. I understand that such lifting may be inconvenient for user - but nothing stops me form adding higher level call in Network.NNTP module. To summarise - the RFC 3977 is on TODO list. Just next to sane final API and stability. I'm very sorry if I've made faux pas. I'm rather new to Haskell community. I 'grown up' in culture 'release early release often' - and version 0.0.1 is very early stage for me. If it is wrong to post it here now - I'm sorry - I've might misread what people responded on #haskell. PS. While part of what I wrote might seem off-topic I also provide response for concerns send on my e-mail. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell/attachments/20090613/fdf34c83/attachment.bin From byorgey at seas.upenn.edu Sat Jun 13 17:28:44 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Jun 13 17:12:14 2009 Subject: [Haskell] Haskell Weekly News: Issue 121 - June 13, 2009 Message-ID: <20090613212844.GA20072@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090613 Issue 121 - June 13, 2009 --------------------------------------------------------------------------- Welcome to issue 121 of HWN, a newsletter covering developments in the [1]Haskell community. Announcements purely functional lazy non-deterministic programming. Sebastian Fischer [2]announced the [3]explicit-sharing library, which supports lazy functional-logic programming in Haskell. nntp 0.0.1. Maciej Piechotka [4]announced the release of [5]nntp, a library to connect to nntp (i.e. mainly USENET) servers. OpenGLRaw 1.0.0.0. Sven Panne [6]announced the release of [7]OpenGLRaw, a low-level binding for OpenGL. The eventual goal is to make the OpenGL package easier to install, more modular and a bit more flexible. pgm-0.1 on Hackage. Frederick Ross [8]announced [9]pgm, a pure Haskell library to read and write PGM images. It seamlessly handles the divide between 1 and 2 byte per pixel images; reads and writes UArrays; can handle multiple PGMs concatenated one after another in a file; and encodes and decodes all comments in the PGM header, which can be used to drop arbitrary metadata into files in a human readable manner. iteratee-0.2.1 released. John Lato [10]announced the release of [11]iteratee-0.2.1, a major update to the iteratee library. This library provides types and functions for performing enumerator/iteratee based I/O operations in Haskell, as [12]described by Oleg. The new version is a large redesign, including support for resumable exceptions and a greatly simplified interface. testrunner-0.9. Reinier Lamers [13]announced [14]testrunner, a new framework for running unit test. It can run unit tests in parallel; can run QuickCheck and HUnit tests as well as simple boolean expressions; and comes with a ready-made main function for your unit test executable. serial-0.2. Frederick Ross [15]announced version 0.2 of [16]serial, a library for working with line-oriented POSIX serial ports. hunp-0.0. Deniz Dogan [17]announced [18]hunp, a command-line utility which automagically calls the right "unpacker" program for you and works on both files and directories. Nemesis : easy task management. Jinjing Wang [19]announced a new release of [20]nemesis, a simple rake-like task management tool. Data.Reify.CSE. Sebastiaan Visser [21]announced the [22]data-reify-cse module, which implements common sub-expression elimination for graphs generated by the Data.Reify package. This package might especially be useful for optimizing simple compilers for referentially transparent domain specific languages. Hac phi accommodation: register by June 15 for reduced rate! Brent Yorgey [23]reminded anyone interested in attending [24]Hac phi that Monday 15 June is the deadline for getting a special reduced hotel rate. alloy-1.0.0 (generic programming). Neil Brown [25]announced the [26]first release of the [27]Allow generic programming library. It is intended to be a fairly fast blend of several other generics approaches, such as SYB (but without the dynamic typing) and Uniplate (but allowing an arbitrary number of target types), for performing transformations on specific types in large tree structures. StrictBench 0.1 - Benchmarking code through strict evaluation. R.A. Niemeijer [28]announced the release of [29]StrictBench, a library for timing full evaluation of values. haskeem 0.7.0 uploaded to hackage. Uwe Hollerbach [30]announced [31]haskeem, a small scheme interpreter written in Haskell. numtype 1.0 -- Type-level (low cardinality) integers. Bjorn Buckwalter [32]announced the [33]Numeric.NumType module, now released as its own package, which implements a unary type-level representation of integers, supporting addition, subtraction, multiplication, and division. Google Summer of Code Progress updates from participants in the 2008 [34]Google Summer of Code. space profiling. Gergely Patai has some [35]pretty graphs generated by his profiling library. haskell-src-exts. Niklas Broberg is [36]quite close to releasing haskell-src-exts 1.0.0, as soon as he has full and correct support for (almost) everything code-related, with only a few things left to do. He also wrote [37]a post explaining the intricacies of parsing code containing the 'forall' keyword (well, whether it is a keyword depends on which extensions are enabled...) fast darcs. Petr Rockai made a bit less progress this week, with finals and other things interfering, but [38]made some progress on some documentation, tracking down a performance regression, and other things. Discussion Adding an ignore function to Control.Monad. Gwern Branwen [39]proposed adding an 'ignore' function to Control.Monad which explicitly changes an m a into a m (). Bikeshedding (and some useful discussion) ensued. Wiki user accounts. Philippa Cowderoy began a [40]discussion of what to do about the current situation with wiki user accounts (namely, that account creation is disabled due to spam, and the one maintainer of the wiki can't always respond to account creation requests instantly). Lightweight type-level dependent programming in Haskell. Ryan Ingram made an interesting [41]post about implementing lightweight closed type classes in Haskell. who's up for a hackathon? (ICFP, late Aug, early Sept). Eric Kow [42]wanted to know who would be interested in having a hackathon immediately before or after ICFP in Edinburgh. Jobs Galois is hiring functional programmers. Don Stewart [43]announced that [44]Galois is hiring! See the announcement for more details. Blog noise [45]Haskell news from the [46]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * Niklas Broberg: [47]GSoC status report, week 3. * Joachim Breitner: [48]Introducing L-seed. * Conal Elliott: [49]Memoizing polymorphic functions - part two. * London Haskell Users Group: [50]Next Meeting: Sean Leather, Fun and generic things to do with EMGM. * David Amos: [51]It's on Hackage!. Haskell for Maths is now just a cabal-install away. * Michael Snoyman: [52]Filename encoding issues. * David Amos: [53]Permutation groups. * Edward Kmett: [54]Recursion Schemes: A Field Guide (Redux). * mightybyte: [55]Intro to HAppS-State. * Conal Elliott: [56]Memoizing polymorphic functions - part one. * Lennart Augustsson: [57]More LLVM. * Roman Cheplyaka: [58]Don't play with your monads. * Galois, Inc: [59]Tech Talk: Orc in Haskell. * Petr Rockai: [60]soc progress 3. Progress on Petr's GSoC darcs project. * Magnus Therning: [61]Using msmtp with darcs. * Erik de Castro Lopo: [62]Debian Maintainer. Erik is now a Debian maintainer, and plans to give Haskell on Debian a much-needed facelift! * Niklas Broberg: [63]What's in a forall?. More Haskell parsing fun. * Well-Typed.Com: [64]GHC, primops and exorcising GMP. * Niklas Broberg: [65]What's in a forall?. More than you might expect! * >>> Zsol: [66]Visualizing the graphrewrite process behind Haskell. Work on the [67]visual-graphrewrite package. * Eric Kow (kowey): [68]testrunner for practical quickcheck. * Sebastian Fischer: [69]Explicit sharing of monadic effects. Purely functional, lazy, non-deterministic programming! * LHC Team: [70]New backend. * >>> James McNeill: [71]Messing with Haskell. * Dan Piponi (sigfpe): [72]Hashing Molecules. * Shin-Cheng Mu: [73]Longest Segment Satisfying Suffix and Overlap-Closed Predicates. * David Amos: [74]Simple graphs with Math.Combinatorics.Graph. David shows off his Haskell for Maths library. * Gergely Patai: [75]More colourful graphs. Graphs from Gergely's GSoC project on profiling. * Bryan O'Sullivan: [76]Case conversion and text 0.3. The text module gets solid, standards-compliant case conversion. * Bjorn Buckwalter: [77]numtype 1.0: Type-level (low cardinality) integers. * >>> J?rn Dinkla: [78]Parallelization with Haskell - Easy as can be. Quotes of the Week * sjanssen: in our sub-culture, "considered harmful" means "burn it with fire" * quicksilver: after all, anyone who insists on talking about himself in the third person is clearly someone to be reckoned with. About the Haskell Weekly News New editions are posted to [79]the Haskell mailing list as well as to [80]the Haskell Sequence and [81]Planet Haskell. [82]RSS is also available, and headlines appear on [83]haskell.org. To help create new editions of this newsletter, please see the information on [84]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [85]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.libraries/11265 3. http://sebfisch.github.com/explicit-sharing 4. http://article.gmane.org/gmane.comp.lang.haskell.general/17271 5. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/nntp 6. http://www.haskell.org//pipermail/haskell/2009-June/021402.html 7. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OpenGLRaw 8. http://article.gmane.org/gmane.comp.lang.haskell.general/17263 9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pgm 10. http://article.gmane.org/gmane.comp.lang.haskell.general/17262 11. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/iteratee 12. http://okmij.org/ftp/Streams.html#iteratee 13. http://article.gmane.org/gmane.comp.lang.haskell.general/17258 14. http://projects.haskell.org/testrunner/ 15. http://article.gmane.org/gmane.comp.lang.haskell.general/17257 16. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/serial 17. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59843 18. http://hackage.haskell.org/package/hunp 19. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59824 20. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/nemesis 21. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59807 22. http://hackage.haskell.org/package/data-reify-cse 23. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59741 24. http://haskell.org/haskellwiki/Hac_%CF%86 25. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59631 26. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/alloy 27. http://twistedsquare.com/Alloy-Tutorial.pdf 28. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59605 29. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/StrictBench 30. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59551 31. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskeem 32. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59543 33. http://dimensional.googlecode.com/ 34. http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2008 35. http://just-bottom.blogspot.com/2009/06/more-colourful-graphs.html 36. http://nibrofun.blogspot.com/2009/06/gsoc-status-report-week-3.html 37. http://nibrofun.blogspot.com/2009/06/whats-in-forall.html 38. http://web.mornfall.net/blog/soc_progress_3.html 39. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/11278 40. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/59814 41. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/59749 42. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/59737 43. http://article.gmane.org/gmane.comp.lang.haskell.general/17264 44. http://www.galois.com/ 45. http://planet.haskell.org/ 46. http://haskell.org/haskellwiki/Blog_articles 47. http://nibrofun.blogspot.com/2009/06/gsoc-status-report-week-3.html 48. https://www.joachim-breitner.de/blog/archives/330-Introducing-L-seed.html 49. http://conal.net/blog/posts/memoizing-polymorphic-functions-part-two/ 50. http://www.londonhug.net/2009/06/12/next-meeting-sean-leather-fun-and-generic-things-to-do-with-emgm/ 51. http://haskellformaths.blogspot.com/2009/06/its-on-hackage.html 52. http://blog.snoyman.com/2009/06/11/filename-encoding-issues/ 53. http://haskellformaths.blogspot.com/2009/06/permutation-groups.html 54. http://comonad.com/reader/2009/recursion-schemes/ 55. http://softwaresimply.blogspot.com/2008/02/intro-to-happs-state.html 56. http://conal.net/blog/posts/memoizing-polymorphic-functions-part-one/ 57. http://augustss.blogspot.com/2009/06/more-llvm-recently-someone-asked-me-on.html 58. http://ro-che.blogspot.com/2009/06/dont-play-with-your-monads.html 59. http://www.galois.com/blog/2009/06/09/tech-talk-orc/ 60. http://web.mornfall.net/blog/soc_progress_3.html 61. http://therning.org/magnus/archives/656 62. http://www.mega-nerd.com/erikd/Blog/CodeHacking/Debian/debian_maintainer.html 63. http://nibrofun.blogspot.com/2009/06/whats-in-forall.html 64. http://blog.well-typed.com/2009/06/ghc-primops-and-exorcising-gmp/ 65. http://nibrofun.blogspot.com/2009/06/whats-in-forall.html 66. http://lazybottom.blogspot.com/2009/06/visualizing-graphrewrite-process-behind.html 67. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/visual-graphrewrite 68. http://koweycode.blogspot.com/2009/06/testrunner-for-practical-quickcheck.html 69. http://www-ps.informatik.uni-kiel.de/~sebf/haskell/explicit-sharing.html 70. http://lhc-compiler.blogspot.com/2009/06/new-backend.html 71. http://playtechs.blogspot.com/2009/06/messing-with-haskell.html 72. http://blog.sigfpe.com/2009/06/hashing-molecules.html 73. http://www.iis.sinica.edu.tw/~scm/2009/longest-segment-satisfying-suffix-and-overlap-closed-predicates/ 74. http://haskellformaths.blogspot.com/2009/06/simple-graphs-with-mathcombinatoricsgra.html 75. http://just-bottom.blogspot.com/2009/06/more-colourful-graphs.html 76. http://www.serpentine.com/blog/2009/06/07/case-conversion-and-text-03/ 77. http://flygdynamikern.blogspot.com/2009/06/announce-numtype-10-type-level-low.html 78. http://blog.dinkla.net/?p=15 79. http://www.haskell.org/mailman/listinfo/haskell 80. http://sequence.complete.org/ 81. http://planet.haskell.org/ 82. http://sequence.complete.org/node/feed 83. http://haskell.org/ 84. http://haskell.org/haskellwiki/HWN 85. http://code.haskell.org/~byorgey/code/hwn/ From simon at joyful.com Sat Jun 13 18:07:30 2009 From: simon at joyful.com (Simon Michael) Date: Sat Jun 13 17:51:10 2009 Subject: [Haskell] ANN: hledger 0.6 released Message-ID: <940603EB-D7A5-40D4-BEF3-E598BB571A3B@joyful.com> I'm pleased to announce the release of hledger 0.6. For docs, online demo etc., see http://hledger.org . Some pre-built binaries are now available at http://hledger.org/ binaries . Or, install with: cabal install hledger [-fhapps] [-fvty]. (Using the latest Haskell Platform, "cabal install hledger -fhapps" works on gnu/ linux, mac and windows. Hurrah!) I'd like to hear feedback, especially if you hit trouble getting started. Happy tracking! - Simon (sm) 2009/06/13 hledger 0.6 ...................... * now cabal-installable on unix, mac, and windows, with Haskell Platform * provide experimental platform binaries * parsing: fix a silly failure to open ledger file paths containing ~ * parsing: show better errors for unbalanced transaction and missing default year * parsing: allow parentheses and brackets inside account names, as ledger does * parsing: fail on empty account name components, don't just ignore * add: description passed as arguments now affects first transaction only * add: better handling of virtual postings and default amounts * print, register: show virtual accounts bracketed/parenthesised * web: improved web ui supporting full patterns & period expressions * new "stats" command reports some ledger statistics * many dev/doc/deployment infrastructure improvements * move website into darcs repo, update home page * move issue tracker to google code Release stats: * Contributors: Simon Michael * Days since last release: 21 * Commits: 94 * Lines of non-test code: 2865 * Tests: 82 * Test coverage: 53% expressions * Known errors: 3 (inconsistent eliding, vty-related failures) * Performance: similar (http://hledger.org/profs/200906131120.bench) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090613/af686ff0/attachment.html From alson at alsonkemp.com Sun Jun 14 01:44:51 2009 From: alson at alsonkemp.com (Alson Kemp) Date: Sun Jun 14 01:28:16 2009 Subject: [Haskell] ANNOUNCE: Turbinado V0.7 Message-ID: <2629c41e0906132244t4094f6a4wac285eec6c95774@mail.gmail.com> Turbinado is a Ruby-On-Rails-like web server and web framework for Haskell. It is designed to make creating web application using Haskell both easy and joyful. Turbinado continues to progress and I'd like to announce Turbinado V0.7. The primary additions are FastCGI support and a new templating system (which includes HAML and HTML support). Additional details are here: http://www.alsonkemp.com/turbinado/announce-turbinado-v07/. In order to accommodate collaboration, I've moved the project's homepage to GitHub: Homepage: http://wiki.github.com/turbinado/turbinado Source code: http://github.com/turbinado/turbinado From Tillmann.Vogt at rwth-aachen.de Sun Jun 14 17:08:56 2009 From: Tillmann.Vogt at rwth-aachen.de (Tillmann Vogt) Date: Sun Jun 14 16:52:13 2009 Subject: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0 In-Reply-To: References: Message-ID: <4A3566E8.1000105@rwth-aachen.de> Sven Panne schrieb: > Am Donnerstag, 11. Juni 2009 19:23:17 schrieb Bryan O'Sullivan: >> [...] I think that "Graphics.Rendering." is clutter, and "OpenGL.GL." seems >> redundant to me. [...] > > I forgot to mention one thing here: "OpenGL.GL" is currently *not* redundant, > there is "OpenGL.GLU" in the OpenGL package, too. GL and GLU are separate > libraries, even living in separate DLLs/*.sos, having separate headers, etc., > so they should be kept separate in Haskell at some level, too. > > Nevertheless, with OpenGL 3.1 GLU is dead, Are you sure? glu is mainly for converting an arbitrary polygon into triangles. This is an art and so obviously wasn't put into hardware or driver. From a previous post I remember that tesselation was mentioned. But looking at some presentation slides from AMD/ATI I understand that tesselation in directx11 is using the following primitive patches: Triangles and Tri-patches, Quads and Quad Patches, Lines and Line Patches, see http://ati.amd.com/developer/gdc/2008/Tatarchuk-Tessellation_GDC08.pdf slide 31. I haven't found a lot of information in the OpenGL 3.1 Spec, so I assume they will do it similar to directx11. So, if glu is still needed, until I use a better algorithm in my library. > anyway, so in future versions there > will be no ".GL" part in the package names. > > Cheers, > S. > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From cetin at sertcom.de Mon Jun 15 23:13:29 2009 From: cetin at sertcom.de (Cetin Sert) Date: Mon Jun 15 22:57:08 2009 Subject: [Haskell] ANNOUNCE: clock 0.1 released Message-ID: <4A370DD9.3010903@sertcom.de> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20090615/e22db663/signature.bin From g9ks157k at acme.softbase.org Tue Jun 16 08:36:41 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Jun 16 08:20:00 2009 Subject: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0 In-Reply-To: <200906121124.19484.Sven.Panne@aedion.de> References: <200906111856.01646.Sven.Panne@aedion.de> <200906121124.19484.Sven.Panne@aedion.de> Message-ID: <200906161436.41467.g9ks157k@acme.softbase.org> Am Freitag, 12. Juni 2009 11:24 schrieb Sven Panne: > A few final remarks: Leaving out "Graphics." completely would be a very bad > idea, the naming hierarchy should reflect the underlying conceptual > hierarchy. The only problem with hierarchies in general is that sometimes > the position in it is not very clear. I have e.g. never fully understood > why "Monad" and "Applicative" are below "Control", but "Foldable" is below > "Data"... This is a reason for me thinking that the naming hierarchy should not reflect the underlying conceptual hierarchy (completely). I?d like to propose a more flat structure. The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever. Graphics.UI is a bad choice in my opinion, since not all user interfaces are graphical (ncurses) and for those who are, it?s not so important anymore that they are (it was important in the 1980ies). So it might be good to change Graphics.UI to just UI. Then we might want to change Graphics.Rendering to just Graphics. What do others think? Best wishes, Wolfgang From bf3 at telenet.be Tue Jun 16 12:23:08 2009 From: bf3 at telenet.be (Peter Verswyvelen) Date: Tue Jun 16 12:06:13 2009 Subject: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0 In-Reply-To: <200906161436.41467.g9ks157k@acme.softbase.org> References: <200906111856.01646.Sven.Panne@aedion.de> <200906121124.19484.Sven.Panne@aedion.de> <200906161436.41467.g9ks157k@acme.softbase.org> Message-ID: <001e01c9ee9e$bbeb8e30$33c2aa90$@be> I completely agree with Wolfgang, but still, defining a hierarchy, even if it is almost flat, is always difficult. I remember when I made videogames in a big team that we had endless discussions of how to arrange the directory structures, only to find out that hierarchies are not ideal, they are a compromise (IMHO for many tasks simple tagging or relation database approaches often work much better to organize data) Cheers, Peter Verswyvelen Software Architect www.anygma.com -----Original Message----- From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Wolfgang Jeltsch Sent: Tuesday, June 16, 2009 2:37 PM To: haskell@haskell.org Subject: Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0 Am Freitag, 12. Juni 2009 11:24 schrieb Sven Panne: > A few final remarks: Leaving out "Graphics." completely would be a very bad > idea, the naming hierarchy should reflect the underlying conceptual > hierarchy. The only problem with hierarchies in general is that sometimes > the position in it is not very clear. I have e.g. never fully understood > why "Monad" and "Applicative" are below "Control", but "Foldable" is below > "Data"... This is a reason for me thinking that the naming hierarchy should not reflect the underlying conceptual hierarchy (completely). I?d like to propose a more flat structure. The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever. Graphics.UI is a bad choice in my opinion, since not all user interfaces are graphical (ncurses) and for those who are, it?s not so important anymore that they are (it was important in the 1980ies). So it might be good to change Graphics.UI to just UI. Then we might want to change Graphics.Rendering to just Graphics. What do others think? Best wishes, Wolfgang _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell __________ Information from ESET Smart Security, version of virus signature database 4159 (20090616) __________ The message was checked by ESET Smart Security. http://www.eset.com __________ Information from ESET Smart Security, version of virus signature database 4159 (20090616) __________ The message was checked by ESET Smart Security. http://www.eset.com From niklas.broberg at gmail.com Tue Jun 16 18:43:47 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Tue Jun 16 18:27:10 2009 Subject: [Haskell] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2) Message-ID: Fellow Haskelleers, I'm pleased to report that I feel I have now completed the first milestone in my GSoC project for haskell-src-exts: Full Code Support. This means I feel ready to take that scary leap that means to drop the safe 0.x version numbering (experimental) and finally make the first stable release, version 1.0.0. But before I take that leap I want the library to be thoroughly tested, so I can with confidence say that it truly *is* stable. Therefore, I hereby announce the release on hackage of haskell-src-exts-0.5.2, which I consider (almost) a release candidate for 1.0.0. * Via cabal: cabal install haskell-src-exts * On Hackage: http://hackage.haskell.org/package/haskell-src-exts-0.5.2 * Via darcs: darcs get http://code.haskell.org/haskell-src-exts I would be delighted if as many as possible would consider testing it on their code, even those of you who feel that you may not have any immediate use of the library, just to cover as much code base as possible in the hunt for potential bugs and misfeatures. Testing it is really easy, four simple steps: > cabal install haskell-src-exts [...] > ghci [...] Prelude> :m Language.Haskell.Exts Prelude Language.Haskell.Exts> parseFile "YourFileHere.(l)hs" If you get a parse error on a file that you feel should have been accepted, let me know! If the parser gives you an AST result for a file that you feel it shouldn't have accepted, let me know! Here's the bug tracker: http://trac.haskell.org/haskell-src-exts/report/1 The reason I say it is "almost" a release candidate is that while I consider the functionality to be in place, I will tidy up the exports, add a few more convenient functions to export, and add a lot of documentation, before I make the actual release. If you have a request for a particularly conventient function to add to the list of exports from the package, it's thus not too late to get it into 1.0.0. :-) What's cool in haskell-src-exts-0.5.2: ============================ * Support for all syntactic extensions supported by GHC, with two exceptions: UnicodeSyntax and NewQualifiedOperators. These will likely be added in the next feature release. Exclusive support for the newly registered XmlSyntax and RegularPatterns extensions. No support (yet) for Hugs-specific extensions (RestrictedTypeSynonyms, ExtensibleRecords, HereDocuments). No support for CPP. Also does not support the GHC-specific relaxation of layout in do-blocks, which is an unregistered extension (that should be registered!). * Support for parametrising the parsing on what extensions it should recognise. With no extensions given, it assumes Haskell98. Note that 'parseFile' will look for language pragmas in your source file to decide what extensions to use when parsing. If you want to be explicit, you can use 'parseFileWithExts', or 'parseFileWithMode' that lets you set a few other things as well. I intend to add some convenient names of extension groups, such as 'ghcExtensions' and 'glasgowExts', this is one area where I would particularly welcome suggestions. * Support for correct fixities of infix operators. By default it uses the fixities defined in the Prelude, as well as in the current document (including local let-bound fixities). Use 'parseFileWithMode' to set a different set of fixities. Language.Haskell.Exts.Fixity defines preludeFixities and baseFixities (all fixities defined in the base package), as well as combinators for defining your own sets. Much thanks to Neil Mitchell for the meat of this code. * No (known) bugs! :-) Special note for users of HaRP/HSP: I've uploaded a new version of hsx, hsx-0.5.0, that works with haskell-src-exts-0.5.2. There is one known bug in this version though, it cannot handle 'proc' entities from the Arrows extensions, I'm still considering how to fix that. In the mean time you can use it just fine, as long as your files don't contain any 'proc' blocks (which the old version couldn't handle anyway). Cheers and happy Haskelling, /Niklas From ashley at semantic.org Tue Jun 16 19:40:45 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Jun 16 19:24:03 2009 Subject: [Haskell] Top Level In-Reply-To: <200906161436.41467.g9ks157k@acme.softbase.org> References: <200906111856.01646.Sven.Panne@aedion.de> <200906121124.19484.Sven.Panne@aedion.de> <200906161436.41467.g9ks157k@acme.softbase.org> Message-ID: <4A382D7D.6020105@semantic.org> (moving to Libraries list) Wolfgang Jeltsch wrote: > The Yampa people and I (the Grapefruit maintainer) already agreed to introduce > a top-level FRP namespace instead of putting FRP under Control or whatever. > Graphics.UI is a bad choice in my opinion, since not all user interfaces are > graphical (ncurses) and for those who are, it?s not so important anymore that > they are (it was important in the 1980ies). So it might be good to change > Graphics.UI to just UI. Then we might want to change Graphics.Rendering to > just Graphics. > > What do others think? I prefer this too. UI and Graphics are different things: doing stuff with images is graphics but not UI, while ncurses or even a command-line is UI but not graphics. -- Ashley Yakeley From niklas.broberg at gmail.com Tue Jun 16 20:35:09 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Tue Jun 16 20:18:30 2009 Subject: [Haskell] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2) In-Reply-To: References: Message-ID: > * Via cabal: cabal install haskell-src-exts Thanks a lot to Brian Lewis for catching the first bug - cabal install doesn't even work for 0.5.2! The problem is that the cabal test machinery can't find the Language.Haskell.Exts modules, unless haskell-src-exts is already installed first... At any rate: I'm pleased to announce haskell-src-exts-0.5.3! Everything else from above still applies. :-) Cheers, /Niklas From Malcolm.Wallace at cs.york.ac.uk Wed Jun 17 05:05:25 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Jun 17 04:51:05 2009 Subject: [Haskell] Re: Top Level In-Reply-To: <200906161436.41467.g9ks157k@acme.softbase.org> References: <200906111856.01646.Sven.Panne@aedion.de> <200906121124.19484.Sven.Panne@aedion.de> <200906161436.41467.g9ks157k@acme.softbase.org> Message-ID: <20090617100525.5490f460.Malcolm.Wallace@cs.york.ac.uk> Wolfgang Jeltsch wrote: > The Yampa people and I (the Grapefruit maintainer) already agreed to > introduce a top-level FRP namespace instead of putting FRP under > Control or whatever. The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it. So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. I do understand that hierarchical classification is inherently problematic, and will never quite fit the ways we think of our modules. But the alternative being proposed here is neither more descriptive, nor more logical. In fact, it is an abandonment of description, in favour of arbitrary naming. A package called foo-1.0 containing a module hierarchy rooted at "Foo." tells me precisely nothing about its contents. It it were rooted at Military.Secret.Foo, at least I would have some clue about what it does, even if the category is inadequate or slightly misleading in certain circumstances. You may argue that only novices are disadvantaged by arbitrary names - once you learn the referent of the name, it is no longer confusing. However, I strongly believe that even experienced users are helped by the continuous re-inforcement of visual links between name and concept. After all, if you are collaboratively building a software artifact that depends on large numbers of library packages, it may not be so easy to keep your internal dictionary of the mapping between names and functionality up-to-date, and in sync with your colleagues. Being just a little bit more explicit in the hierarchy is a one-time cost at time of writing, that reaps perceptual benefits long into the future for yourself, and those maintainers who will follow you. Regards, Malcolm From anton at appsolutions.com Wed Jun 17 05:29:05 2009 From: anton at appsolutions.com (Anton van Straaten) Date: Wed Jun 17 05:12:24 2009 Subject: [Haskell] Re: Top Level In-Reply-To: <20090617100525.5490f460.Malcolm.Wallace@cs.york.ac.uk> References: <200906111856.01646.Sven.Panne@aedion.de> <200906121124.19484.Sven.Panne@aedion.de> <200906161436.41467.g9ks157k@acme.softbase.org> <20090617100525.5490f460.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <4A38B761.2080106@appsolutions.com> Malcolm Wallace wrote: > Wolfgang Jeltsch wrote: > >> The Yampa people and I (the Grapefruit maintainer) already agreed to >> introduce a top-level FRP namespace instead of putting FRP under >> Control or whatever. > > The problem with a top-level namespace like FRP is that it is a cryptic > acronym: it means nothing to a novice, and may be easily confused with > other acronyms by an expert. I believe top-level names should _at_the_ > _very_least_ be minimally descriptive of the category of things that > live in it. > > So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, > or even just Reactive.Yampa etc. Besides, it hardly seems necessary to emphasize "Functional" and "Programming" in the Haskell context... From sebf at informatik.uni-kiel.de Wed Jun 17 06:13:11 2009 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Wed Jun 17 05:56:37 2009 Subject: [Haskell] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2) In-Reply-To: References: Message-ID: <38E6B5B2-8590-4400-8AD3-178C8411B867@informatik.uni-kiel.de> On Jun 17, 2009, at 12:43 AM, Niklas Broberg wrote: > Testing it is > really easy, four simple steps: > >> cabal install haskell-src-exts > [...] >> ghci > [...] > Prelude> :m Language.Haskell.Exts > Prelude Language.Haskell.Exts> parseFile "YourFileHere.(l)hs" This script may even simplify testing of large code bases: ------- #! /usr/bin/env runhaskell > import System > import System.IO > import Data.Char > import Language.Haskell.Exts > > import Prelude hiding ( catch ) > import Control.Exception ( catch, SomeException ) > > main = getArgs >>= mapM_ parse > where parse file = do hSetBuffering stdout NoBuffering > putStr $ file ++ ": " > catch (parseFile file >>= putStr . check) $ > \e -> print (e :: SomeException) > where check (ParseOk _) = replicate (2+length file) '\b' > check (ParseFailed loc msg) = unlines [err] > where err = msg ++ " at " ++ > show (srcLine loc) ++ ":" ++ > show (srcColumn loc) ------- After making it executable you can run it as shell script and pass names of Haskell files -- (something like) this will check all Haskell files (literate or not) in your home directory: find ~ -name "*hs" | xargs parse-haskell.lhs Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) From marlowsd at gmail.com Wed Jun 17 06:25:45 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jun 17 06:09:04 2009 Subject: [Haskell] Re: Top Level In-Reply-To: <20090617100525.5490f460.Malcolm.Wallace@cs.york.ac.uk> References: <200906111856.01646.Sven.Panne@aedion.de> <200906121124.19484.Sven.Panne@aedion.de> <200906161436.41467.g9ks157k@acme.softbase.org> <20090617100525.5490f460.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <4A38C4A9.2000702@gmail.com> On 17/06/2009 10:05, Malcolm Wallace wrote: > Wolfgang Jeltsch wrote: > >> The Yampa people and I (the Grapefruit maintainer) already agreed to >> introduce a top-level FRP namespace instead of putting FRP under >> Control or whatever. > > The problem with a top-level namespace like FRP is that it is a cryptic > acronym: it means nothing to a novice, and may be easily confused with > other acronyms by an expert. I believe top-level names should _at_the_ > _very_least_ be minimally descriptive of the category of things that > live in it. > > So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, > or even just Reactive.Yampa etc. I think this raises an interesting point. When we first started using hierarchical module names, we established a guiding principle: that the module name should reflect functionality first, so that the hierarchy can help you to find the functionality you're looking for. Including non-functionality-related information in module names should only be used to distinguish between multiple implementations of related functionality (e.g. Test.HUnit vs. Test.QuickCheck). That was before Hackage, which has largely taken over the role of helping users discover functionality. Obviously Hackage has a long way to go - it only has rudimentary categories right now, and in the past we've discussed having a more elaborate tagging scheme, but nevertheless Hackage seems like the right place to provide functionality-discovery. Before packages, there was a single module namespace shared by everyone. Now, for better or worse, there is a single package namespace shared by everyone, and the module namespace is essentially a free-for-all. Where does that leave module names? What are the advantages of having a rigidly-defined module hierarchy based on functionality classification? The only reasons I can think of are: * Choosing module names based on some generally agreed-upon guidelines makes it less likely that one package's module names will clash with another. * Packages that are conglomerations of different kinds of functionality (e.g. base) benefit from functionality-based module naming. * Source code doesn't refer to packages, it only refers to module names. So if you're trying to understand a piece of source code, it helps if the module names it imports are descriptive and unique. On the other hand, a module name tells you nothing of the provenance or the version of the module it refers to, so arguably source code without its dependencies is already less than useful. So why shouldn't OpenGL be naming its modules OpenGL.*, rather than Graphics.Rendering.OpenGL.*? Personally, I can't think of any sufficiently compelling reasons any more. Discuss! (replies set to libraries@haskell.org) Cheers, Simon From niklas.broberg at gmail.com Wed Jun 17 07:00:33 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Wed Jun 17 06:43:51 2009 Subject: [Haskell] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2) In-Reply-To: <7D9668D5-949B-4AF0-A4E8-B00FAA6B0441@sebfisch.de> References: <7D9668D5-949B-4AF0-A4E8-B00FAA6B0441@sebfisch.de> Message-ID: Hi Sebastian, > This script may even simplify testing of large code bases: Thanks a lot, very useful! I'll add that to the darcs repository if you don't mind. :-) Cheers, /Niklas From sebf at informatik.uni-kiel.de Wed Jun 17 08:38:49 2009 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Wed Jun 17 08:22:18 2009 Subject: [Haskell-cafe] Re: [Haskell] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2) In-Reply-To: References: <7D9668D5-949B-4AF0-A4E8-B00FAA6B0441@sebfisch.de> Message-ID: <77946D36-6F49-4823-A3C2-044A59DA899C@informatik.uni-kiel.de> On Jun 17, 2009, at 1:00 PM, Niklas Broberg wrote: > Thanks a lot, very useful! I'll add that to the darcs repository if > you don't mind. :-) feel free! Here is a cleaned-up and updated version that can also read from stdin: #! /usr/bin/env runhaskell > import Language.Haskell.Exts > > import System ( getArgs ) > import System.IO ( hGetContents, stdin ) > import Prelude hiding ( catch ) > import Control.Exception ( catch, SomeException ) > > main :: IO () > main = do args <- getArgs > input <- hGetContents stdin > mapM_ parse (args ++ lines input) > where parse file = catch (parseFile file >>= check) $ > \e -> putStrLn $ file ++ ": " ++ show (e::SomeException) > > check :: ParseResult a -> IO () > check (ParseOk _) = return () > check (ParseFailed loc msg) = putStrLn err > where err = srcFilename loc ++ ": " ++ msg ++ " at " ++ > show (srcLine loc) ++ ":" ++ > show (srcColumn loc) -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 163 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell/attachments/20090617/14b6d9a4/PGP-0001.bin From conal at conal.net Wed Jun 17 14:01:05 2009 From: conal at conal.net (Conal Elliott) Date: Wed Jun 17 13:44:40 2009 Subject: [HOpenGL] Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0 In-Reply-To: <200906121124.19484.Sven.Panne@aedion.de> References: <200906111856.01646.Sven.Panne@aedion.de> <200906121124.19484.Sven.Panne@aedion.de> Message-ID: On Fri, Jun 12, 2009 at 2:24 AM, Sven Panne wrote: > > A few final remarks: Leaving out "Graphics." completely would be a very bad > idea, the naming hierarchy should reflect the underlying conceptual > hierarchy. > The only problem with hierarchies in general is that sometimes the position > in > it is not very clear. > Clay Shirky's points in include that this "sometimes" is more like "nearly always", and that the heart of the problem is "the" in "the position" (in a hierarchy). This problem and others discussed at http://www.shirky.com/writings/ontology_overrated.html . I have e.g. never fully understood why "Monad" and "Applicative" are below > "Control", but "Foldable" is below "Data"... > Monoid as well. Type classes in general cut across distinctions like Control and Data, so I don't think we'll ever have a comfortable place to put them in the existing hierarchy. If anything, I recommend the top-level name "Class". - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090617/10f682f8/attachment.html From niklas.broberg at gmail.com Wed Jun 17 18:42:35 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Wed Jun 17 18:25:54 2009 Subject: [Haskell] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2) In-Reply-To: References: Message-ID: Hi all, > This means I feel ready to take that scary leap that means to drop the > safe 0.x version numbering (experimental) and finally make the first > stable release, version 1.0.0. But before I take that leap I want the > library to be thoroughly tested, so I can with confidence say that it > truly *is* stable. Therefore, I hereby announce the release on hackage > of haskell-src-exts-0.5.2, which I consider (almost) a release > candidate for 1.0.0. I have just uploaded haskell-src-exts-0.5.4 to hackage, which is 1.0.0 rc2. Thanks a lot to those who tested the previous version, and please continue to test and report! Changes in 0.5.4: ================== Three fixed bugs: * BangPatterns are now parsed correctly in function bindings. * Single-item class contexts are now accepted with parenthesis around them (doh!). * The haddock documentation (paltry as it is) can now be built. Thanks a lot to Brian Lewis for the patch, which rearranges my commented guard clause. Haddock apparently didn't like the '{- | guard = ...' line... One new feature: * The parseFileX family of functions now all recognize and act on LANGUAGE pragmas (previously only parseFile did). There is now also an extra field in the ParseMode called 'ignoreLanguagePragmas', which defaults to False. Set it to True if you really want parseFile et al to disregard LANGUAGE pragmas. (Note that you can always use the simple 'parse' function that doesn't try to be clever at all.) Cheers, /Niklas From g9ks157k at acme.softbase.org Thu Jun 18 12:03:03 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Jun 18 11:46:16 2009 Subject: [Haskell] Re: Top Level In-Reply-To: <20090617100525.5490f460.Malcolm.Wallace@cs.york.ac.uk> References: <200906111856.01646.Sven.Panne@aedion.de> <200906161436.41467.g9ks157k@acme.softbase.org> <20090617100525.5490f460.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <200906181803.03246.g9ks157k@acme.softbase.org> Am Mittwoch, 17. Juni 2009 11:05 schrieb Malcolm Wallace: > The problem with a top-level namespace like FRP is that it is a cryptic > acronym: it means nothing to a novice, and may be easily confused with > other acronyms by an expert. I believe top-level names should _at_the_ > _very_least_ be minimally descriptive of the category of things that > live in it. > > So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, > or even just Reactive.Yampa etc. Where should the modules of Conal?s reactive package be rooted then? Under Control.Reactive.Reactive? Best wishes, Wolfgang From g9ks157k at acme.softbase.org Thu Jun 18 12:04:04 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Jun 18 11:47:17 2009 Subject: [Haskell] Re: Top Level In-Reply-To: <4A38B761.2080106@appsolutions.com> References: <200906111856.01646.Sven.Panne@aedion.de> <20090617100525.5490f460.Malcolm.Wallace@cs.york.ac.uk> <4A38B761.2080106@appsolutions.com> Message-ID: <200906181804.04662.g9ks157k@acme.softbase.org> Am Mittwoch, 17. Juni 2009 11:29 schrieb Anton van Straaten: > Malcolm Wallace wrote: > > The problem with a top-level namespace like FRP is that it is a cryptic > > acronym: it means nothing to a novice, and may be easily confused with > > other acronyms by an expert. I believe top-level names should _at_the_ > > _very_least_ be minimally descriptive of the category of things that > > live in it. > > > > So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, > > or even just Reactive.Yampa etc. > > Besides, it hardly seems necessary to emphasize "Functional" and > "Programming" in the Haskell context... When we discussed where to place modules of FRP libraries in the hierarchy, it was argued that FRP had become a ?brand?. It?s not just about programming reactive systems but describes a certain basic approach to it. Best wishes, Wolfgang From niklas.broberg at gmail.com Thu Jun 18 19:52:30 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Jun 18 19:35:48 2009 Subject: [Haskell] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2) In-Reply-To: References: Message-ID: > I have just uploaded haskell-src-exts-0.5.4 to hackage, which is 1.0.0 > rc2. Thanks a lot to those who tested the previous version, and please > continue to test and report! Another day, another release candidate. Please see haskell-src-exts-0.5.5, 1.0.0 rc3. Thanks a lot to all reports, and please keep up the good work! Changes in 0.5.5: ================ * BangPatterns are now correctly handled everywhere (I think - tricksy little imps they are). I would like to put out a special call for tests of files that use bang patterns, in particular if they appear in "strange" locations inside patterns. * TypeFamilies now implies KindSignatures, as in GHC. * Chained contexts, e.g. foo :: Eq a => Show a => a, are now handled correctly. * . is no longer considered a reserved operator but a special operator when explicit forall is enabled, which means Prelude.. now parses correctly. * Parenthesised patterns inside list patterns no longer require RegularPatterns enabled. * List expressions are no longer translated to tuple expressions by the fixity mangler (yes, it did that)... Cheers, /Niklas From marks at ittc.ku.edu Fri Jun 19 14:57:12 2009 From: marks at ittc.ku.edu (Mark Huntington Snyder) Date: Fri Jun 19 14:40:22 2009 Subject: [Haskell] 12th Annual ICFP Contest Message-ID: <50750.129.237.127.199.1245437832.squirrel@webmail.ittc.ku.edu> The University of Kansas is pleased to call for participation in the 12th Annual ICFP Programming Contest, hosted by the Computer Systems Design Laboratory at the Information and Telecommunication Technology Center. http://icfpcontest.org/ The contest, associated with the International Conference on Functional Programming, will be held on the weekend of June 26-29. The contest task will be released sixteen seconds after 13:00 Central Daylight Time (US) on Friday, and entries will be accepted until 13:00:16 CDT on Monday. There is no preregistration required, and participation is free and open to all. Teams may participate from any location, and may use any programming language(s). Last year, over 330 teams participated from around the globe. Solutions can be submitted to a lightning round (within the first 24 hours) and the regular 72-hour competition. First place, lightning round, and judges' choice prizes will be awarded, which will include prize money to help defray the costs of travel to the conference for the winners as well as small cash prizes. In addition, the winners of the contest will receive bragging rights for the programming language of their choice. This makes the contest a popular avenue for demonstrating the superiority of a favorite language, or for exercising an experimental tool. Stay tuned for more information as the contest approaches! Read the contest blog (http://www.icfpcontest.org/wordpress) or subscribe to the RSS feed (http://www.icfpcontest.org/wordpress/?feed=rss2) to receive timely updates before and during the contest. ~ 2009 Contest Organizers ~ The University of Kansas CSDL From igloo at earth.li Fri Jun 19 15:35:11 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jun 19 15:18:20 2009 Subject: [Haskell] Re: Top Level In-Reply-To: <200906181803.03246.g9ks157k@acme.softbase.org> References: <200906111856.01646.Sven.Panne@aedion.de> <200906161436.41467.g9ks157k@acme.softbase.org> <20090617100525.5490f460.Malcolm.Wallace@cs.york.ac.uk> <200906181803.03246.g9ks157k@acme.softbase.org> Message-ID: <20090619193511.GA24622@matrix.chaos.earth.li> On Thu, Jun 18, 2009 at 06:03:03PM +0200, Wolfgang Jeltsch wrote: > Am Mittwoch, 17. Juni 2009 11:05 schrieb Malcolm Wallace: > > The problem with a top-level namespace like FRP is that it is a cryptic > > acronym: it means nothing to a novice, and may be easily confused with > > other acronyms by an expert. I believe top-level names should _at_the_ > > _very_least_ be minimally descriptive of the category of things that > > live in it. > > > > So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, > > or even just Reactive.Yampa etc. > > Where should the modules of Conal?s reactive package be rooted then? Under > Control.Reactive.Reactive? I don't know anything about the package, but if putting the modules directly under Control.Reactive wouldn't make sense then it sounds to me like the package name is poor (too generic). Thanks Ian From niklas.broberg at gmail.com Fri Jun 19 19:31:21 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri Jun 19 19:14:33 2009 Subject: [Haskell] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2) In-Reply-To: References: Message-ID: Hi all, > Another day, another release candidate. Please see > haskell-src-exts-0.5.5, 1.0.0 rc3. Thanks a lot to all reports, and > please keep up the good work! Here we go again. Please have a look at haskell-src-exts-0.5.6, or 1.0.0 rc4. Thanks again for the reports, they're all truly invaluable. Changes in 0.5.6: =================== One major addition: * Support for relaxed layout in do-blocks! Yes, I caved in, after I got enough reports about it. Two stupid bugs fixed: * MagicHash ConId lexemes can now be followed by things other than space characters (like closing brackets: foo :: (Int#)). * ctypes (i.e. types with contexts and forall-quantifiers) can now appear inside tuples and lists if the proper extensions are on. Cheers, /Niklas From byorgey at seas.upenn.edu Sun Jun 21 14:10:18 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sun Jun 21 13:53:27 2009 Subject: [Haskell] Haskell Weekly News: Issue 122 - June 21, 2009 Message-ID: <20090621181018.GA26745@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090621 Issue 122 - June 21, 2009 --------------------------------------------------------------------------- Welcome to issue 122 of HWN, a newsletter covering developments in the [1]Haskell community. Are you ready for the [2]12th Annual ICFP programming contest? It begins this Friday, don't miss it! Let's reclaim Haskell's rightful place as the programming language of choice for discriminating hackers. Announcements Haskell protocol-buffers version 1.5.0. Chris Kuklewicz [3]announced version 1.5.0 of the [4]protocol-buffers, [5]protocol-buffers-descriptor, and [6]hprotoc packages to Hackage. This catches up to Google's version 2.1.0: support for "repeated" fields for primitive types; fields can now be marked deprecated; the type name resolver will no longer resolve type names to fields; and more. 12th Annual ICFP Contest. Mark Huntington Snyder [7]announced the 12th Annual [8]ICFP Programming Contest, hosted by the University of Kansas Computer Systems Design Laboratory at the Information and Telecommunication Technology Center. The contest will be held on the weekend of June 26-29. The contest task will be released sixteen seconds after 13:00 Central Daylight Time (US) on Friday, and entries will be accepted until 13:00:16 CDT on Monday. There is no preregistration required, and participation is free and open to all. Teams may participate from any location, and may use any programming language(s). Read the [9]contest blog or subscribe to the [10]RSS feed to receive timely updates before and during the contest. clock 0.1 released. Cetin Sert [11]announced the release of [12]clock, a package for convenient access to high-resolution clock and timer functions of different operating systems. It is planned to consist of two layers; the lower layer will provide direct access to OS-specific clock and timer functions like clock_gettime of Posix or GetTickCount of Windows, and its upper layer shall then provide a common API for all supported systems. Currently only the lower level is being developed. Turbinado V0.7. Alson Kemp [13]announced version 0.7 of [14]Turbinado, a Ruby-On-Rails-like web server and web framework for Haskell. It is designed to make creating web application using Haskell both easy and joyful. The primary additions in version 0.7 are FastCGI support and a new templating system (which includes HAML and HTML support). Additional details can be found [15]here. haskeline-class. Antoine Latter [16]announced [17]haskeline-class, a small library providing a newtyped MonadState instance for haskeline which lifts the class operations to an inner monad (as opposed to its existing instance). hyena. Johan Tibell [18]announced the first release of [19]hyena, a library for building web servers, based on the work on [20]iteratee style I/O by Oleg Kiselyov. The library allows you to create web servers that consume their input incrementally, without resorting to lazy I/O. This should lead to more predictable resource usage. Haskell-based iPhone development. Conal Elliott [21]announced a [22]collaboration wiki page for anyone working with Haskell to make iPhone apps. Fwd: Boston Haskell June 23rd meeting: openings for Lightning Talks. Ravi Nanavati [23]announced that there are several available slots for "lightning" (5 minute) talks at the June 23 meeting of the [24]Boston Area Haskell Users' Group. haskell-src-exts 1.0.0 rc1. Niklas Broberg [25]announced a series of release candidates for haskell-src-exts-1.0.0 (as of this writing, the most recent release candidate is version 0.5.6). This version is intended to fully support parsing of almost all Haskell extensions. Please help with testing! BostonHaskell: Next meeting - June 23rd at MIT CSAIL Reading Room (32-G882). Ravi Nanavati [26]announced the second meeting of the [27]Boston Area Haskell Users' Group, scheduled for Tuesday, June 23rd from 6:30pm - 8:30pm. It will be held in the MIT CSAIL Reading Room (32-G882, i.e. a room on the 8th floor of the Gates Tower of the MIT's Stata Center at 32 Vassar St in Cambridge, MA). Talks include "Automagic Font Conversion with Haskell Typeclasses" by Frank Berthold, and "Intermediate Language Representations via GADTs" by Nirav Dave. traversal transformations. Sjoerd Visscher [28]exhibited some code for Church-encoded container structures using their Foldable instance, and later [29]announced the [30]fmlist package based on the same code, along with a surprising example of a lazy 'middle-infinite' list (where elements can be taken from the beginning or the end!). hledger 0.6 released. Simon Michael [31]announced the release of [32]hledger 0.6. See the announcement for a list of the new features and other information. Discussion Adding swap to Data.Tuple. roconnor [33]proposed adding swap and swap' functions to Data.Tuple. Revamping the module hierarchy. Johan Tibell began an interesting [34]discussion about package names, module names, and the module hierarchy. Confusion on the third monad law when using lambda abstractions. Jon Strait [35]asked about the third monad law, leading to some clarification on what precisely the law says, and some interesting discussion on idiomatic use of the (<=<) (Kleisli composition) operator. Need some help with an infinite list. Gunther Schmidt [36]asked for some help generating a particular infinite list, and got a number of interesting suggestions. Blog noise [37]Haskell news from the [38]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * Thomas ten Cate: [39]Cosmetics. Nice-looking icons for EclipseFP! * Niklas Broberg: [40]GSoC status report, week 4. More release candidates for haskell-src-exts 1.0.0. * >>> Uwe Hoffmann: [41]publishing nike runs, part 4: string templates. Real-world example of using HStringTemplate. * Andy Gill: [42]Call for Participation in the 12th Annual ICFP Programming Contest!. June 26-29! * Sebastian Fischer: [43]Reinventing Haskell Backtracking. * Remco Niemeijer: [44]Programming Praxis - Monte Carlo factorization. Remco implements Pollard's factorization algorithm in 9 lines of Haskell. * >>> Lee Duhem: [45]Understanding Functions Which Use 'instance Monad []' by Equational Reasoning. * Alex McLean: [46]Patterns in Haskell. A Haskell music generation EDSL. * David Amos: [47]Group generators for graph symmetries. * >>> adam: [48]Experience writing a ray tracer in Haskell. Adam's final project in a Haskell class taught by Mark Jones and Tim Sheard. * Petr Rockai: [49]soc progress 4. * Yaakov Nemoy: [50]Haskell Bindings to C from Start to Finish. Yaakov outlines his experience getting c2hs and the FFI to work. * Alex McLean: [51]Patterns in Haskell. Representing rhythmic patterns in Haskell. * >>> Abhishek Tiwari: [52]Haskell for Bioinformatics. * Roman Cheplyaka: [53]Shootout. A hilarious comic featuring sound advice on Haskell optimization. * Ketil Malde: [54]Dephd updates. * Neil Mitchell: [55]Draft paper on Derive, comments wanted. * Remco Niemeijer: [56]Programming Praxis - Who Owns The Zebra?. * Erik de Castro Lopo: [57]Two More for the Debian New Queue.. * David Amos: [58]Graph symmetries. * Alson Kemp: [59]Announce: Turbinado V0.7. * Gergely Patai: [60]You can draw your own graphs now!. * >>> Jens Petersen: [61]Haskell cabal-install rocks . Quotes of the Week * Botje: oh man. de bruijn again kicked me to groin the easy fix is to label your groin as (-1) :) * Pseudonym: Telling dons that something has been added to the shootout is the new telling Oleg that it can't be done in the type system. About the Haskell Weekly News New editions are posted to [62]the Haskell mailing list as well as to [63]the Haskell Sequence and [64]Planet Haskell. [65]RSS is also available, and headlines appear on [66]haskell.org. To help create new editions of this newsletter, please see the information on [67]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [68]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://icfpcontest.org/ 3. http://article.gmane.org/gmane.comp.lang.haskell.libraries/11331 4. http://hackage.haskell.org/package/protocol-buffers 5. http://hackage.haskell.org/package/protocol-buffers-descriptor 6. http://hackage.haskell.org/package/hprotoc 7. http://article.gmane.org/gmane.comp.lang.haskell.general/17298 8. http://icfpcontest.org/ 9. http://www.icfpcontest.org/wordpress 10. http://www.icfpcontest.org/wordpress/?feed=rss2 11. http://article.gmane.org/gmane.comp.lang.haskell.general/17279 12. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/clock 13. http://article.gmane.org/gmane.comp.lang.haskell.general/17277 14. http://wiki.github.com/turbinado/turbinado 15. http://www.alsonkemp.com/turbinado/announce-turbinado-v07/ 16. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60246 17. http://hackage.haskell.org/package/haskeline-class 18. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60117 19. http://hackage.haskell.org/package/hyena 20. http://hackage.haskell.org/package/iteratee 21. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60104 22. http://haskell.org/haskellwiki/IPhone 23. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60091 24. http://www.haskell.org/haskellwiki/Boston_Area_Haskell_Users%27_Group 25. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59993 26. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59991 27. http://www.haskell.org/haskellwiki/Boston_Area_Haskell_Users%27_Group 28. http://article.gmane.org/gmane.comp.lang.haskell.cafe/59894 29. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60120 30. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fmlist 31. http://www.haskell.org/pipermail/haskell-cafe/2009-June/062787.html 32. http://hledger.org/ 33. http://article.gmane.org/gmane.comp.lang.haskell.libraries/11326 34. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/11325 35. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/60105 36. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/59999 37. http://planet.haskell.org/ 38. http://haskell.org/haskellwiki/Blog_articles 39. http://eclipsefp.wordpress.com/2009/06/20/cosmetics/ 40. http://nibrofun.blogspot.com/2009/06/gsoc-status-report-week-4.html 41. http://www.codemanic.com/uwe/2009/06/publishing-nike-runs-part-4-string-templates.html 42. http://blog.unsafeperformio.com/?p=53 43. http://www-ps.informatik.uni-kiel.de/~sebf/pub/atps09.html 44. http://bonsaicode.wordpress.com/2009/06/19/programming-praxis-monte-carlo-factorization/ 45. http://leeduhem.wordpress.com/2009/06/19/understanding-functions-which-use-list-monad-by-equational-reasoning/ 46. http://yaxu.org/patterns-in-haskell/ 47. http://haskellformaths.blogspot.com/2009/06/group-generators-for-graph-symmetries.html 48. http://blog.finiteimprobability.com/2009/06/18/experience-writing-a-ray-tracer-in-haskell/ 49. http://web.mornfall.net/blog/soc_progress_4.html 50. http://loupgaroublond.blogspot.com/2009/06/haskell-bindings-to-c-from-start-to.html 51. http://yaxu.org/patterns-in-haskell/ 52. http://www.abhishek-tiwari.com/2009/06/haskell-for-bioinformatics.html 53. http://ro-che.blogspot.com/2009/06/shootout.html 54. http://blog.malde.org/index.php/2009/06/16/dephd-updates/ 55. http://neilmitchell.blogspot.com/2009/06/draft-paper-on-derive-comments-wanted.html 56. http://bonsaicode.wordpress.com/2009/06/16/programming-praxis-who-owns-the-zebra/ 57. http://www.mega-nerd.com/erikd/Blog/CodeHacking/Debian/safe_uniplate.html 58. http://haskellformaths.blogspot.com/2009/06/graph-symmetries.html 59. http://www.alsonkemp.com/turbinado/announce-turbinado-v07/ 60. http://just-bottom.blogspot.com/2009/06/you-can-draw-your-own-graphs-now.html 61. http://juhp.blogspot.com/2009/06/haskell-cabal-install-rocks.html 62. http://www.haskell.org/mailman/listinfo/haskell 63. http://sequence.complete.org/ 64. http://planet.haskell.org/ 65. http://sequence.complete.org/node/feed 66. http://haskell.org/ 67. http://haskell.org/haskellwiki/HWN 68. http://code.haskell.org/~byorgey/code/hwn/ From niklas.broberg at gmail.com Sun Jun 21 20:59:02 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Jun 21 20:42:13 2009 Subject: [Haskell] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2) In-Reply-To: References: Message-ID: Dear all, I'm pleased to announce to you haskell-src-exts-0.5.7, which is truly the first *real* release candidate for 1.0.0. By real, I mean that I could consider releasing it in this state. It is feature complete, fully documented, and has no remaining known bugs. But before I do, I'd like to run it past you all one final time. Please help me test it! Via cabal: cabal install haskell-src-exts Via darcs: darcs get http://code.haskell.org/haskell-src-exts On hackage: http://hackage.haskell.org/package/haskell-src-exts-0.5.7 Changes from 0.5.6: ===================== Two small bug fixes: * Fixed a bug in the parser productions that made SCC pragmas virtually unusable. Note that this fix includes a change in the AST for expressions. * Fixed a bug in the fixity mangler where some subexpressions were left out. Three new "features": * The partial 'unParseOk' is removed in favor of the total 'fromParseOk', which throws an error if the parse failed. * Defined 'glasgowExts' as the set of extensions enabled by GHC's -fglasgow-exts. You might typically want to use it together with 'parseFileWithExts', to get -fglasgow-exts as a default (since haskell-src-exts doesn't take OPTIONS_GHC pragmas into account). * Complete haddock documentation for the whole package. Please, help me one last time! :-) Cheers and thanks, /Niklas From g9ks157k at acme.softbase.org Mon Jun 22 08:39:52 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Jun 22 08:22:54 2009 Subject: [Haskell] Re: Top Level In-Reply-To: <20090619193511.GA24622@matrix.chaos.earth.li> References: <200906111856.01646.Sven.Panne@aedion.de> <200906181803.03246.g9ks157k@acme.softbase.org> <20090619193511.GA24622@matrix.chaos.earth.li> Message-ID: <200906221439.53150.g9ks157k@acme.softbase.org> Am Freitag, 19. Juni 2009 21:35 schrieb Ian Lynagh: > > > So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, > > > or even just Reactive.Yampa etc. > > > > Where should the modules of Conal?s reactive package be rooted then? > > Under Control.Reactive.Reactive? > > I don't know anything about the package, but if putting the modules > directly under Control.Reactive wouldn't make sense then it sounds to me > like the package name is poor (too generic). reactive is a specific FRP implementation by Conal Elliott. So it shouldn?t be put directly under Control.Reactive since other reasonable FRP implementations exist. Best wishes, Wolfgang From colin at colina.demon.co.uk Mon Jun 22 10:15:20 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Mon Jun 22 09:58:25 2009 Subject: [Haskell] ANNOUNCE: Program to set the GNOME desktop background picture randomly Message-ID: I've just uploaded gnome-desktop to Hackage. This periodically picks a random picture from $HOME/Pictures, and sets it as the GNOME desktop background. It does this periodically. As a result, I now see a different beautiful picture of a dragonfly every 30 seconds, without needing to wait for the screensaver to kick in. Timings and directory can be set on the command line. -- Colin Adams Preston Lancashire From yann at kierun.org Mon Jun 22 10:41:12 2009 From: yann at kierun.org (Yann Golanski) Date: Mon Jun 22 10:24:13 2009 Subject: [Haskell] ANNOUNCE: Program to set the GNOME desktop background picture randomly In-Reply-To: References: Message-ID: <20090622144112.GA15926@kierun.org> Quoth Colin Paul Adams on Mon, Jun 22, 2009 at 15:15:20 +0100 > This periodically picks a random picture from $HOME/Pictures, and sets > it as the GNOME desktop background. It does this periodically. Have a look at http://hackage.haskell.org/package/backdropper which does a similar thing but is not gnome specific. -- yann@kierun.org -= H+ =- www.kierun.org PGP: 009D 7287 C4A7 FD4F 1680 06E4 F751 7006 9DE2 6318 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell/attachments/20090622/fc8ef231/attachment.bin From icfp.publicity at googlemail.com Mon Jun 22 11:28:32 2009 From: icfp.publicity at googlemail.com (Matthew Fluet (ICFP Publicity Chair)) Date: Mon Jun 22 11:11:37 2009 Subject: [Haskell] ICFP09 Call for Participation Message-ID: <53ff55480906220828k360d6c0dt26d53d7451098f68@mail.gmail.com> ===================================================================== Call for Participation The 14th ACM SIGPLAN International Conference on Functional Programming (ICFP 2009) http://www.cs.nott.ac.uk/~gmh/icfp09.html Edinburgh, Scotland, 31 August - 2 September 2009 ===================================================================== ICFP 2009 provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. Preliminary program: * Accepted papers: + http://web.cecs.pdx.edu/~apt/icfp09_accepted_papers/accepted.html * Invited speakers: + Guy Steele -- Organizing Functional Code for Parallel Execution: or, foldl and foldr Considered Slightly Harmful + Benjamin Pierce -- Lambda, the Ultimate TA: Using a Proof Assistant to Teach Programming Language Foundations +Dan Piponi -- Commutative Monads, Diagrams and Knots Schedule including related workshops: * Aug 30: ACM SIGPLAN Workshop on ML * Aug 30: ACM SIGPLAN Workshop on Generic Programming * Aug 31-Sep 2: ICFP09 * Sep 3: ACM SIGPLAN Haskell Symposium * Sep 3: ACM SIGPLAN Developer Tracks on Functional Programming * Sep 4: Commercial Users of Functional Programming * Sep 4: ACM SIGPLAN Workshop on Mechanizing Metatheory * Sep 4: ACM SIGPLAN Workshop on Approaches and Applications of Inductive Programming * Sep 5: ACM SIGPLAN Erlang Workshop * Sep 5: ACM SIGPLAN Developer Tracks on Functional Programming * Sep 5: ACM SIGPLAN Haskell Implementors Workshop Registration information: * http://www.regmaster.com/conf/icfp2009.html * Early registration deadline: July 30, 2009 Local arrangements (including travel and accommodation): * http://www.haskell.org/haskellwiki/ICFP_2009_Local_Arrangements * Conference reservation/rate deadline: July 20, 2009 * ICFP09 coincides with the final week of the Edinburgh International Festival, one of the premier arts and cultural festivals in the world. The opportunity to attend the Festival is a plus! Due to the popularity of Edinburgh during the festival period, we strongly recommend booking accommodation early. Conference organizers: * General Chair: Graham Hutton (University of Nottingham) * Program Chair: Andrew Tolmach (Portland State University) * Local Arrangements Chairs: Philip Wadler (University of Edinburgh), Kevin Hammond (University of St Andrews), and Gregory Michaelson (Heriot-Watt University) * Workshop Co-Chairs: Christopher Stone (Harvey Mudd College), and Michael Sperber (DeinProgramm) * Programming Contest Chair: Andrew Gill (University of Kansas) * Publicity Chair: Matthew Fluet (Toyota Technological Institute at Chicago) ===================================================================== ===================================================================== And, don't forget about the ICFP Programming Contest this weekend!! * http://www.icfpcontest.org * Friday, June 26 to Monday, June 29 * Organizers: Computer Systems Design Laboratory (University of Kansas) From ryant5000 at gmail.com Mon Jun 22 17:12:22 2009 From: ryant5000 at gmail.com (Ryan Trinkle) Date: Mon Jun 22 16:55:20 2009 Subject: [Haskell] Haskell on the iPhone Message-ID: <442d2c4c0906221412i3736e6afx9e6d1718a186332b@mail.gmail.com> Dear Haskellers, Recently, there's been a groundswell of activity in the Haskell community regarding the Haskell's use in developing iPhone games. The iPhone is a powerful, innovative platform (with a great monetization scheme, to boot), and it's not surprising that many of us would want to develop apps for it in our favorite language. I am proud to announce today that my company, iPwn Studios Inc., is currently preparing to release an open source patch to GHC that allows it to output binaries for iPhone OS. The patch will be released under a BSD license as soon as possible and hopefully integrated into the GHC main-line in the near future. As the first (to my knowledge) Haskell-based game studio, iPwn Studios is committed to giving back to the Haskell community through open source - contributing to a rising tide that lifts us all. I would like to take this opportunity to propose the creation of a haskell-iphone mailing list, so that all Haskellers working with the iPhone - whether for profit or for pleasure - can come together to make Haskell a force to be reckoned with in the burgeoning iPhone App marketplace. Best wishes, Ryan Trinkle President, iPwn Studios Inc. P.S.: If you wish to be involved in the preparation of the GHC patch or in the creation of iPwn Studios' first game, don't hesitate to contact me by email (ryant5000@gmail.com), AIM (RyanT5000), or IRC (RyanT5000 on irc.freenode.net). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090622/fda13fdb/attachment.html From bulat.ziganshin at gmail.com Mon Jun 22 17:15:47 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Jun 22 16:58:54 2009 Subject: [Haskell] Haskell on the iPhone In-Reply-To: <442d2c4c0906221412i3736e6afx9e6d1718a186332b@mail.gmail.com> References: <442d2c4c0906221412i3736e6afx9e6d1718a186332b@mail.gmail.com> Message-ID: <94883181.20090623011547@gmail.com> Hello Ryan, Tuesday, June 23, 2009, 1:12:22 AM, you wrote: > I am proud to announce today that my company, iPwn Studios Inc., is > currently preparing to release an open source patch to GHC that > allows it to output binaries for iPhone OS.? The patch will be > released under a BSD license as soon as possible and hopefully das ist fantastisch! :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From niklas.broberg at gmail.com Mon Jun 22 20:36:07 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Jun 22 20:19:11 2009 Subject: [Haskell] ANN: haskell-src-exts-1.0.0 Message-ID: Fellow Haskelleers, It is with great pleasure I hereby announce the first stable release of the haskell-src-exts package, version 1.0.0! 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. I wish to thank the glorious Haskell community, for giving me the chance to work on this project as part of Haskell.org's GSoC programme, but also for simply being such a nice place to be! Special thanks to everyone who helped me with testing and bug reports during the final stretch of release candidates, in particular the many excellent reports from Ganesh Sittampalam, Sebastian Fischer, and Neil Mitchell who is also mentoring the project. You're all awesome! haskell-src-exts-1.0.0: ================= Via cabal: cabal install haskell-src-exts-1.0.0 Via darcs: darcs get http://code.haskell.org/haskell-src-exts On hackage: http://hackage.haskell.org/package/haskell-src-exts-1.0.0 Changes from 0.5.7, the last release candidate: ====================================== * CPP lines are no longer ignored, which means haskell-src-exts will now invariably give a parse error on files with CPP pragmas in them. CPP is not supported by haskell-src-exts, and this is more intuitive than parsing e.g. all branches of an #if pragma, which is invariably give unintended results. * Fixed a stupid introduced bug where extensions passed int he parse mode were ignored. * fromParseOk is now exported, not just defined (doh). * ScopedTypeVariables now implies TypeOperators, as per GHC. I'm sure there are more implications that are missing from haskell-src-exts, I will add them as I find out about them. Thanks once again, and Happy Haskell Hacking to all! Cheers, /Niklas (*) The only two exceptions are NewQualifiedOperators and UnicodeSyntax. From leon.p.smith at gmail.com Mon Jun 22 22:31:34 2009 From: leon.p.smith at gmail.com (Leon Smith) Date: Mon Jun 22 22:14:36 2009 Subject: [Haskell] ANN: Reusable Corecursive Queues via Continuations Message-ID: In a purely functional setting, real-time queues are traditionally thought to be much harder to implement than either real-time stacks or amortized O(1) queues. In ?Circular Programs and Self-Referential Structures,? [1] Lloyd Allison uses corecursion to implement a queue by defining a lazy list in terms of itself. This provides a simple, efficient, and attractive implementation of real-time queues. Now, control-monad-queue is available on hackage [2], which offers this technique in a reusable library. As Allison's queue is not fully persistent, it cannot be a first class value; rather they are encoded in specific algorithms written in an extended continuation passing style, and the use of continuations seems necessary in order to abstract the corecursive queue operations. Also, a substantially revised draft of the associated paper, "Lloyd Allison's Corecursive Queues: Why Continuations Matter" is now available. [3] This paper will appear in the upcoming Monad Reader issue 14, and comments would be most appreciated. It derives a reusable implementation in an explicit continuation-passing style from Allison's original code, demonstrates an alternate reusable implementation in direct style using mapCont, and argues that mapCont cannot be expressed in terms of callCC, return, and (>>=). Finally, this approach performs well in practice, when compiled with optimization using GHC. However, performance has regressed from GHC 6.8.3 to 6.10.3, and there is a curious performance anomaly associated with the generalized corecursive abstraction. [1] http://www.csse.monash.edu.au/~lloyd/tildeFP/1989SPE/ [2] http://hackage.haskell.org/package/control-monad-queue [3] http://blog.melding-monads.com/2009/06/22/control-monad-queue/ Best, Leon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090622/20cb582a/attachment-0001.html From DekuDekuplex at Yahoo.com Tue Jun 23 01:15:32 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Tue Jun 23 01:03:03 2009 Subject: [Haskell] Re: Haskell on the iPhone References: <442d2c4c0906221412i3736e6afx9e6d1718a186332b@mail.gmail.com> Message-ID: <64p0459pio4am1jn02qkk46klsftta373r@4ax.com> On Mon, 22 Jun 2009 17:12:22 -0400, Ryan Trinkle wrote: >[...] > >I would like to take this opportunity to propose the creation of a >haskell-iphone mailing list, so that all Haskellers working with the iPhone >- whether for profit or for pleasure - can come together to make Haskell a >force to be reckoned with in the burgeoning iPhone App marketplace. This idea sounds great to me. Please count my vote as in favor of the list. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From pds at di.uevora.pt Tue Jun 23 05:28:07 2009 From: pds at di.uevora.pt (Pedro Salgueiro) Date: Tue Jun 23 05:23:44 2009 Subject: [Haskell] INAP 2009: 2nd Call for Papers Message-ID: <1245749287.5216.35.camel@rebirth> [apologies for cross-posting; please distribute] --- (PLEASE DISTRIBUTE) ------------------------------------------------------------ Second Call for Papers INAP 2009 18th International Conference on Applications of Declarative Programming and Knowledge Management November 5-7, 2009 Evora, Portugal http://www.di.uevora.pt/inap2009/ http://inap.dialogengines.com/ ------------------------------------------------------------ Organized by the Portuguese AI Society (APPIA), the INAP Committee and the Society of Logic Programming (GLP e.V.) == Overview == Declarative Programming is a family of advanced paradigms for the modeling and solving of complex problems. These specification and implementation methods have attracted more and more attention over the past years, e.g. in the domains of databases and natural language processing, for modeling and the processing of combinatorial problems, and for establishing systems for the web. == INAP 2009 == INAP is a communicative and dense forum for intensive discussion of applications of important technologies related to Prolog, Logic and Constraint Programming as well as closely related advanced software. It comprehensively covers the impact of programmable logic solvers in the Internet Society, its underlying technologies, and leading edge applications in industry, commerce, government, and societal services. INAP 2009 continues a tradition of successful workshops cast around the applications of declarative programming, which were held in Kobe (1997), Tokyo (1995, 1996, 1998 - 2001), Potsdam (2004), Fukuoka (2005) and Wuerzburg (2007). We invite the submission of high quality papers on the described topics, especially, but not exclusively, on different aspects of Declarative Programming, Constraint Processing and Knowledge Management as well as their use for Distributed Systems and the Web: - Knowledge Management, e.g. Data Mining, Decision Support, Deductive Databases - Distributed Systems and the Web, e.g. Agents and Concurrent Engineering, Semantic Web - Constraints, e.g. Constraint Systems, Extensions of Constraint (Logic) Programming - Theoretical Foundations, e.g. Deductive Databases, Nonmonotonic Reasoning - Systems and Tools for Academic and Industrial Use - Knowledge-based Web Services - Logic Solvers and Applications == Workshop Format == The technical program of the workshop will include invited presentations (to be announced), regular technical sessions with presentations of the accepted papers, system demonstrations and a panel discussion. == Conference Venue == The conference will be held at the University of Evora, Portugal in November 5-7, 2009. Evora is a nice and quiet historical city located in the south of Portugal that can be reached from Lisbon by train or coach in under 2 hours. It is a small city of 60.000 inhabitants, 120 km inland from Lisbon and classified by Unesco as World Heritage. The University of Evora was established in the 16th Century and is the 2nd oldest Portuguese University. The social program is promising since the region is very rich in historical sites (Stone Age, Roman, Medieval and Renaissance remains) and also offers a very special gastronomy. See http://en.wikipedia.org/wiki/%C3%89vora for more information. == Important Dates == Paper Submission Deadline: June 29, 2009 Notifications to Authors: August 17, 2009 Camera-ready Version Deadline: September 14, 2009 INAP 2009 Workshop: November 5-7, 2009 == Submission Guidelines == Participants should submit a paper (maximum 15 pages, PDF format), describing their work in topics relevant to the workshop. Accepted papers will be presented during the workshop. At least one author of an accepted contribution is expected to register for the workshop, and present the paper. All submissions should include the author's name(s), affiliation, complete mailing address, and email address. Authors are requested to prepare their submissions, following the LNCS/LNAI Springer format. Please see: http://www.springer.de/comp/lncs/authors.html for further details. The submission should be submitted through the electronic submission site: http://www.easychair.org/conferences/?conf=inap2009 The deadline for receipt of submissions is June 29, 2009. Papers received after this date will not be reviewed. Eligible papers will be peer-reviewed by at least three members of the Program Committee. Authors will be notified via email of the results by August 17, 2009. Authors of accepted papers are expected to improve their paper based on reviewers' comments and to send a camera ready version of their manuscripts by September 14, 2009. Accepted papers will be included in the workshop proceedings, which will be distributed to the participants. As in previous editions, we plan to publish selected papers in a proceedings volume in the Springer Lecture Notes in Artificial Intelligence (LNAI) series. == Organizing Committee == Vitor Nogueira vbn AT di.uevora.pt Salvador Abreu spa AT di.uevora.pt Pedro Salgueiro pds AT di.uevora.pt Universidade de Evora Portugal == Program Committee == Salvador Abreu, University of Evora, Portugal (co-chair) Sergio Alvarez, Boston College, USA Philippe Codognet, CNRS/JFLI, Tokyo, Japan Vitor Santos Costa, University of Porto, Portugal Daniel Diaz, University of Paris I, France Ulrich Geske, University of Potsdam, Germany Gopal Gupta, UT Dallas, USA Petra Hofstedt, Technical University of Berlin, Germany Ulrich Neumerkel, Technical University of Vienna, Austria Vitor Nogueira, University of Evora, Portugal Enrico Pontelli, New Mexico State University, USA Irene Rodrigues, University of Evora, Portugal Carolina Ruiz, Worcester Polytechnic Institute, USA Dietmar Seipel, University of Wuerzburg, Germany (co-chair) Terrance Swift, CENTRIA, Portugal Hans Tompits, Technical University of Vienna, Austria Masanobu Umeda, Kyushu Institute of Technology, Japan Armin Wolf, Fraunhofer FIRST, Berlin, Germany Osamu Yoshie, Waseda University, Japan == Contact Information == inap2009@di.uevora.pt Universidade de Evora Departamento de Informatica Largo dos Colegiais, 2 7004-516 Evora - PORTUGAL From niklas.broberg at gmail.com Tue Jun 23 07:35:44 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Tue Jun 23 07:18:43 2009 Subject: [Haskell] Re: [Haskell-cafe] Re: ANN: haskell-src-exts-1.0.0 In-Reply-To: References: Message-ID: Hi Maur?cio, > How far is Unicode from beeing parsed? It doesn't seem to be > a huge step (from my ill-informed viewpoint), and it would > not let behind those who are happy to be able to declare names > in their own native language. (Oh, and sorry for resorting to > politically correct blackmail...) Unicode in identifiers and symbols actually already works, assuming you don't use the non-Unicode-aware parseFile, parseFileWithExts or parseFileWithMode (which all use Prelude.readLine). What doesn't work is to use the Unicode versions of special symbols like ->, => etc. I'm waiting for a stable and blessed unicode-aware text package to replace utf8-string, before we have one of those then my support would only be half-hearted at best. But in the mean time you can use the readLine provided by utf8-string, and then parseFileContents on that, which should give you the politically correct names. ;-) Cheers, /Niklas From john at repetae.net Tue Jun 23 10:38:43 2009 From: john at repetae.net (John Meacham) Date: Tue Jun 23 10:21:43 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.1 Message-ID: <20090623143843.GC29066@sliver.repetae.net> Hi, this is to announce the release of jhc 0.6.1. The jhc homepage with distribution information is at http://repetae.net/computer/jhc/ The main new feature in this release is a much simplified cross-compilation mechanism. While cross-compilation was always possible with jhc, it used to involve manually copying the C file and calling gcc with the right options on it, now this is taken care of by jhc. A (popular) example would be setting up an iPhone cross compilation target. For instance with the SDK setup I have, I would simply add the following to a file ~/.jhc/targets.ini [iphone] cc=arm-apple-darwin cflags+=-I/usr/local/arm-apple-darwin/include merge=le32 then you can compile iphone binaries with ; jhc --cross -miphone HelloWorld.hs the targets mechanism is extensible at run-time and I have included native unix, win32, osx-intel and osx-powerpc targets. But certainly many more interesting ones are possible. Some I have tested have been a nokia N770 as a target and an atheros MIPS based router running dd-wrt. There is more information on cross compilation in the jhc manual at http://repetae.net/computer/jhc/manual.html#crosscompilation jhc is also now available in the repetae yum repository which you can get at via ; rpm -i http://repetae.net/yum/repetae-repo-1.0-3.noarch.rpm ; yum install jhc Enjoy! John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From matt at mattelder.org Wed Jun 24 02:51:39 2009 From: matt at mattelder.org (Matthew Elder) Date: Wed Jun 24 02:34:54 2009 Subject: [Haskell] ANNOUNCE: sendfile-0.1 Message-ID: <987d172d0906232351ob7a3a1co54e83078639d35ea@mail.gmail.com> Announcing sendfile-0.1: A library which exposes zero-copy sendfile functionality in a portable way. http://hackage.haskell.org/package/sendfile-0.1 Right now it supports natively linux 2.6+ (maybe older too) and windows 2000+ -- on other platforms it will fall back seamlessly to a portable haskell implementation. Please test it out and send your experiences / bug reports to HAppS@googlegroups.com. Patches for other platforms also welcome (but please preserve the existing style). Recommended initial testing steps: cabal install sendfile wget http://patch-tag.com/r/sendfile/snapshot/current/content/raw/test.hs runghc test.hs open http://127.0.0.1:8000 in your web browser and see if test.hs was rendered properly (firefox recommended) see which mode it was rendered in (stdout will say one of WIN32_SENDFILE, LINUX_SENDFILE, or PORTABLE_SENDFILE) Happy Hacking! Matthew Elder -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090624/835c9e01/attachment.html From matt at mattelder.org Wed Jun 24 02:54:54 2009 From: matt at mattelder.org (Matthew Elder) Date: Wed Jun 24 02:38:08 2009 Subject: [Haskell] ANNOUNCE: happstack-0.3.2 Message-ID: <987d172d0906232354l2a0455fejea6cf553b5f6edf4@mail.gmail.com> Announcing happstack-0.3.2: It was released several days ago to hackage, but here is the official announcement! List of recorded changes (many improvements were not documented): * Modularization of the example application using the component system * All packages now require Cabal >= 1.6 * Repository metadata added to cabal description * Moved Combined Logging from Happstack.Server to Happstack.Server.AccessLog.Combined * Added Happstack.Util.Mail: a simple email interface which utilizes a smarthost * SimpleHTTP: look and lookPairs now assume utf-8 from the browser * Space leak fixed in Happstack.Util.Timeout * A fix for an issue where alphanumeric Accept-Encoding Requests made the parser fail * Fixes for some command-line browsers such as links * Guards now have fall-through semantics * Various updates & additions to documentation * Code beautification * Bugfix to Happstack.Util.Cron to accept intervals up to maxBound * addition of a strict version of fileServe "fileServeStrict" * fileServe (lazy) behaves more reliably now and escapes before any filters can be applied Regards, Matthew Elder -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090624/db1bc4c7/attachment.html From michael.dever2 at mail.dcu.ie Wed Jun 24 04:03:14 2009 From: michael.dever2 at mail.dcu.ie (Michael Dever) Date: Wed Jun 24 03:46:09 2009 Subject: [Haskell] Re: Haskell on the iPhone In-Reply-To: <64p0459pio4am1jn02qkk46klsftta373r@4ax.com> References: <442d2c4c0906221412i3736e6afx9e6d1718a186332b@mail.gmail.com> <64p0459pio4am1jn02qkk46klsftta373r@4ax.com> Message-ID: I'm in. Mick On Tue, Jun 23, 2009 at 6:15 AM, Benjamin L.Russell wrote: > On Mon, 22 Jun 2009 17:12:22 -0400, Ryan Trinkle > wrote: > > >[...] > > > >I would like to take this opportunity to propose the creation of a > >haskell-iphone mailing list, so that all Haskellers working with the > iPhone > >- whether for profit or for pleasure - can come together to make Haskell a > >force to be reckoned with in the burgeoning iPhone App marketplace. > > This idea sounds great to me. Please count my vote as in favor of the > list. > > -- Benjamin L. Russell > -- > Benjamin L. Russell / DekuDekuplex at Yahoo dot com > http://dekudekuplex.wordpress.com/ > Translator/Interpreter/ Mobile: +011 81 80-3603-6725 > "Furuike ya, kawazu tobikomu mizu no oto." > -- Matsuo Basho^ > > _______________________________________________ > 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/20090624/2fdc24d0/attachment-0001.html From agocorona at gmail.com Wed Jun 24 05:59:38 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Wed Jun 24 05:42:35 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.1 In-Reply-To: <20090623143843.GC29066@sliver.repetae.net> References: <20090623143843.GC29066@sliver.repetae.net> Message-ID: One question that is not clear in the documentation:Is JHC just a Haskell 98 compiler? Has some extensions? 2009/6/23 John Meacham > > Hi, this is to announce the release of jhc 0.6.1. The jhc homepage with > distribution information is at http://repetae.net/computer/jhc/ > > The main new feature in this release is a much simplified > cross-compilation mechanism. While cross-compilation was always possible > with jhc, it used to involve manually copying the C file and calling gcc > with the right options on it, now this is taken care of by jhc. > > A (popular) example would be setting up an iPhone cross compilation > target. For instance with the SDK setup I have, I would simply add the > following to a file ~/.jhc/targets.ini > > [iphone] > cc=arm-apple-darwin > cflags+=-I/usr/local/arm-apple-darwin/include > merge=le32 > > then you can compile iphone binaries with > > ; jhc --cross -miphone HelloWorld.hs > > the targets mechanism is extensible at run-time and I have included > native unix, win32, osx-intel and osx-powerpc targets. But certainly > many more interesting ones are possible. Some I have tested have been a > nokia N770 as a target and an atheros MIPS based router running dd-wrt. > > > There is more information on cross compilation in the jhc manual at > http://repetae.net/computer/jhc/manual.html#crosscompilation > > jhc is also now available in the repetae yum repository which you can > get at via > > ; rpm -i http://repetae.net/yum/repetae-repo-1.0-3.noarch.rpm > ; yum install jhc > > > Enjoy! > > John > > -- > John Meacham - ?repetae.net?john? - http://notanumber.net/ > _______________________________________________ > 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/20090624/1e04bcb6/attachment.html From sweirich at cis.upenn.edu Wed Jun 24 11:15:25 2009 From: sweirich at cis.upenn.edu (Stephanie Weirich) Date: Wed Jun 24 10:58:44 2009 Subject: [Haskell] (no subject) Message-ID: <40D88B3F-AF2A-4030-8DB4-12937630E7CB@cis.upenn.edu> ===================================================================== Call for Participation ACM SIGPLAN Haskell Symposium 2009 http://haskell.org/haskell-symposium/2009/ Edinburgh, Scotland, 3 September 2009 ===================================================================== The ACM SIGPLAN Haskell Symposium 2009 will be co-located with the 2009 International Conference on Functional Programming (ICFP). The purpose of the Haskell Symposium is to discuss experiences with Haskell and future developments for the language. The scope of the symposium includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. Preliminary program: * http://haskell.org/haskell-symposium/2009/schedule.html REGISTRATION IS NOW OPEN: * http://www.regmaster.com/conf/icfp2009.html * Early registration deadline: July 30, 2009 Local arrangements (including travel and accommodation): * http://www.haskell.org/haskellwiki/ICFP_2009_Local_Arrangements * Conference reservation/rate deadline: July 20, 2009 * ICFP09 & Haskell 09 coincides with the final week of the Edinburgh Festival, one of the premier arts and cultural festivals in the world. The opportunity to attend the Festival is a plus! Due to the popularity of Edinburgh during the festival period, we strongly recommend booking accommodation early. See you in Edinburgh, Stephanie Weirich Haskell 2009 Program Chair ===================================================================== p.s., don't forget about the ICFP Programming Contest this weekend!! * http://www.icfpcontest.org * Friday, June 26 to Monday, June 29 * Organizers: Computer Systems Design Laboratory (University of Kansas) From hectorg87 at gmail.com Wed Jun 24 18:25:54 2009 From: hectorg87 at gmail.com (Hector Guilarte) Date: Wed Jun 24 18:09:07 2009 Subject: [Haskell] Using unsafePerformIO safely Message-ID: <69630b260906241525u5becf460oced564d2ec3b8ee7@mail.gmail.com> Hello, I made a GCL compiler using Alex and Happy and now I'm making the interpreter to that program. Here's the deal: First of all, I'm no expert in the usage of monads. Now: Whenever a "show" instruction is found in any GCL program while the interpretation is being done it is supposed to print on the stdout the string or the aritmetic expresion it was called with, so I guessed I need to run an IO operation and continue the interpretation of my program. I managed to do this using unsafePerformIO and `seq` like is shown below. My question is: Is it safe to use it this way? So far it is working great, but I need to be sure I'm using it in a "safe" way. Like I said, I'm no expert in monads and the System.IO.Unsafe documentation says: " *unsafePerformIO* :: IOa -> a This is the "back door" into the IOmonad, allowing IOcomputation to be performed at any time. For this to be safe, the IOcomputation should be free of side effects and independent of its environment. " I don't know if the IO computation I'm doing is free of side effects and independent of its enviroment :s. (is just hPutStr stdout ....) Also I've read something about my code not being executed for sure or something like that. Can somebody check the code and tell me if I'm "safe" with it? Thanks a lot! Here's the code: -- Tabla is my Symbol Table of the program being interpreted evalInstruccion:: Instruccion -> Tabla -> Tabla evalInstruccion (ShowY showY) tabla = myRunIO (evalShow showY tabla) evalInstruccion _ tabla = tabla -- There are many other Instructions here missing wich are not relevant to my question {-# NOINLINE myRunIO #-} myRunIO:: (Tabla, IO()) -> Tabla myRunIO tupla = ((unsafePerformIO (snd tupla)) `seq` (fst tupla)) -- Here's the unsafePerformIO.... Am I safe? evalShow:: ShowY -> Tabla -> (Tabla, IO()) evalShow (ShowS string) tabla = (tabla,(hPutStr stdout string)) evalShow (ShowE expr) tabla = (tabla,(hPutStr stdout (show (evalExpr expr tabla)))) -- Don't worry about evalExpr, it works and returns an Int -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090624/085c177d/attachment.html From hectorg87 at gmail.com Wed Jun 24 18:30:20 2009 From: hectorg87 at gmail.com (Hector Guilarte) Date: Wed Jun 24 18:13:32 2009 Subject: [Haskell] Re: Using unsafePerformIO safely In-Reply-To: <69630b260906241525u5becf460oced564d2ec3b8ee7@mail.gmail.com> References: <69630b260906241525u5becf460oced564d2ec3b8ee7@mail.gmail.com> Message-ID: <69630b260906241530k73dbbcd6td6b7b7c4eccd2ec0@mail.gmail.com> Sorry, I just realized I sent the e-mail to the wrong mailing list. My bad! On Thu, Jun 25, 2009 at 5:55 PM, Hector Guilarte wrote: > Hello, > > I made a GCL compiler using Alex and Happy and now I'm making the > interpreter to that program. Here's the deal: > > First of all, I'm no expert in the usage of monads. Now: > > Whenever a "show" instruction is found in any GCL program while the > interpretation is being done it is supposed to print on the stdout the > string or the aritmetic expresion it was called with, so I guessed I need to > run an IO operation and continue the interpretation of my program. I managed > to do this using unsafePerformIO and `seq` like is shown below. My question > is: Is it safe to use it this way? So far it is working great, but I need to > be sure I'm using it in a "safe" way. Like I said, I'm no expert in monads > and the System.IO.Unsafe documentation says: > > " > *unsafePerformIO* :: IOa -> a > This is the "back door" into the IOmonad, allowing > IOcomputation to be performed at any time. For this to be safe, the > IOcomputation should be free of side effects and independent of its > environment. > " > > I don't know if the IO computation I'm doing is free of side effects and > independent of its enviroment :s. (is just hPutStr stdout ....) > > Also I've read something about my code not being executed for sure or > something like that. Can somebody check the code and tell me if I'm "safe" > with it? > > Thanks a lot! > > Here's the code: > > -- Tabla is my Symbol Table of the program being interpreted > evalInstruccion:: Instruccion -> Tabla -> Tabla > evalInstruccion (ShowY showY) tabla = myRunIO (evalShow showY tabla) > evalInstruccion _ tabla = tabla -- There are many other Instructions > here missing wich are not relevant to my question > > {-# NOINLINE myRunIO #-} > myRunIO:: (Tabla, IO()) -> Tabla > myRunIO tupla = ((unsafePerformIO (snd tupla)) `seq` (fst tupla)) -- Here's > the unsafePerformIO.... Am I safe? > > evalShow:: ShowY -> Tabla -> (Tabla, IO()) > evalShow (ShowS string) tabla = (tabla,(hPutStr stdout string)) > evalShow (ShowE expr) tabla = (tabla,(hPutStr stdout (show (evalExpr expr > tabla)))) -- Don't worry about evalExpr, it works and returns an Int > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090624/6b8ccea5/attachment.html From jochem at functor.nl Wed Jun 24 18:34:17 2009 From: jochem at functor.nl (Jochem Berndsen) Date: Wed Jun 24 18:17:16 2009 Subject: [Haskell] Using unsafePerformIO safely In-Reply-To: <69630b260906241525u5becf460oced564d2ec3b8ee7@mail.gmail.com> References: <69630b260906241525u5becf460oced564d2ec3b8ee7@mail.gmail.com> Message-ID: <4A42A9E9.4050503@functor.nl> Hector Guilarte wrote: > I made a GCL compiler using Alex and Happy and now I'm making the > interpreter to that program. Here's the deal: > > First of all, I'm no expert in the usage of monads. Now: > > Whenever a "show" instruction is found in any GCL program while the > interpretation is being done it is supposed to print on the stdout the > string or the aritmetic expresion it was called with, so I guessed I need to > run an IO operation and continue the interpretation of my program. I managed > to do this using unsafePerformIO and `seq` like is shown below. My question > is: Is it safe to use it this way? So far it is working great, but I need to > be sure I'm using it in a "safe" way. Like I said, I'm no expert in monads > and the System.IO.Unsafe documentation says: > > " > *unsafePerformIO* :: > IOa > -> a > This is the "back door" into the > IOmonad, > allowing > IOcomputation > to be performed at any time. For this to be safe, the > IOcomputation > should be free of side effects and independent of its > environment. > " > > I don't know if the IO computation I'm doing is free of side effects and > independent of its enviroment :s. (is just hPutStr stdout ....) Well, writing to the standard output is certainly a side effect. (This does not mean that you cannot use unsafePerformIO. The compiler, however, may assume that any value is free from side effects. This means that you could get, in theory, less or more output from your program than you want. In this sense it is not "safe".) > Also I've read something about my code not being executed for sure or > something like that. Can somebody check the code and tell me if I'm "safe" > with it? It's "safe" in the sense that it probably won't blow up your computer. It may also work. On the other hand, I would not recommend using unsafePerformIO in this way. I see two possibilities for resolving this issue: * (ugly) run your GCL (Guarded Command Language?) interpreter in the IO monad, and using "print"/"putStr"/... whenever you encounter a 'show' statement in the GCL program. * (nicer/Haskellier) adapt your interpreter such that it returns a list of Strings to output. You have then a purely functional interpreter, and in the main function of your program you can print this list. This will be lazily evaluated as the GCL program runs. You now have a very nice separation of clean, pure code, and impure code in the IO monad (your "main" function, which can be pretty small in your case). To avoid boilerplate, you can use the Writer monad, for example, but others may have better suggestions. Kind regards, -- Jochem Berndsen | jochem@functor.nl GPG: 0xE6FABFAB From john at repetae.net Wed Jun 24 21:03:03 2009 From: john at repetae.net (John Meacham) Date: Wed Jun 24 20:45:58 2009 Subject: [Haskell] ANNOUNCE: jhc 0.6.1 In-Reply-To: References: <20090623143843.GC29066@sliver.repetae.net> Message-ID: <20090625010302.GA13322@sliver.repetae.net> On Wed, Jun 24, 2009 at 11:59:38AM +0200, Alberto G. Corona wrote: > One question that is not clear in the documentation:Is JHC just a Haskell 98 > compiler? Has some extensions? It is mainly a haskell 98 compiler, but does have several extensions. However, not all of them correspond to GHC extensions and it is missing some notable ones such as MPTCs, but has some other interesting ones such as first class existential types. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From gdweber at iue.edu Sat Jun 27 18:47:33 2009 From: gdweber at iue.edu (Gregory D. Weber) Date: Sat Jun 27 18:30:29 2009 Subject: [Haskell] ANNOUNCE: Cal3D animation library Message-ID: <20090627224733.GA14151@squirrel.localdomain> The Cal3D for Haskell project provides a partial binding to the C++ Cal3D animation library. The project homepage is http://haskell.org/haskellwiki/Cal3d_animation There are three packages available on hackage: * cal3d-0.1 is a Haskell binding to the Cal3D library itself. * cal3d-opengl-0.1 adds a few functions for using Cal3D with OpenGL. * cal3d-examples-0.1 provides a simple example based on the Cally Demo. Cal3D is a C++ library for skeletal-based character animation. It is platform-independent and independent of any particular graphics API. In fact, it does not actually render the animation, but provides hooks that the graphics API (such as OpenGL) can use to do the actual drawing. (As far as I know, though, the only graphics API available for Haskell is OpenGL.) For more information about the (C++) Cal3D library, please see * Cal3D FAQ: http://cal3d.sourceforge.net/docs/api/html/cal3dfaq.html * Cal3D Homepage: http://home.gna.org/cal3d/ -- ___ ___ __ _ / _ \ / _ \| | | | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \____/\_____/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550 From aslatter at gmail.com Sun Jun 28 13:52:22 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Jun 28 13:35:04 2009 Subject: [Haskell] ANNOUNCE: X Haskell Bindings 0.3 Message-ID: <694519c50906281052v2bd8f992h9565ad5f36c6baac@mail.gmail.com> I'd like to announce the 0.3.* series release of the X Haskell Bindings. This release, like the prior 0.2.* series focuses on making the API prettier. This release is based on the XCB protocol descriptions version 1.5 This does mean that there's a good chance this is a breaking release for any code compiled against 0.2.*. The goal of XHB is to provide a Haskell implementation of the X11 wire protocol, similar in spirit to the X protocol C-language Binding (XCB). On Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhb Source: darcs get http://community.haskell.org/~aslatter/code/xhb/ New this release: * In 0.2, a lot of the core protocol requests, events and replies were updated to use prettier Haskell datatypes for the various enums and bitmasks. Thanks to Peter Harris's work on the protocol description XML files, these niceties have extended out to all of the extension requests, events and replies and such. * Due to name clashes, I the type-names for events and errors now include an "Event" or "Error" suffix. For example, the type "Notify" has become "NotifyEvent". * Now based on the protocol description version 1.5, from 1.4. Related projects: X protocol C-language Binding: http://xcb.freedesktop.org/ From byorgey at seas.upenn.edu Mon Jun 29 16:06:07 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Mon Jun 29 15:48:45 2009 Subject: [Haskell] Haskell Weekly News: Issue 123 - June 29, 2009 Message-ID: <20090629200606.GA9088@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090629 Issue 123 - June 29, 2009 --------------------------------------------------------------------------- Welcome to issue 123 of HWN, a newsletter covering developments in the [1]Haskell community. A bit late this week since over the weekend I was trying to get some unruly satellites to behave (with moderate success). Anyway, some fun stuff this week: Haskell on the iPhone; new libraries for 3D animation, web development, session types; new releases of haskell-src-exts and darcs; and more. Also, if it seems that there haven't been many quotes lately, it's because people haven't been @remembering very many in #haskell. I cannot telepathically sense (via the Haskell-force, hereafter known as the "Horce") when someone says something funny. Announcements Haskell Symposium call for participation. Stephanie Weirich [2]announced that [3]registration is now open for the [4]ACM SIGPLAN Haskell Symposium 2009, to be held on 3 September 2009 in Edinburgh, Scotland (co-located with ICFP). The purpose of the Haskell Symposium is to discuss experiences with Haskell and future developments for the language. The scope of the symposium includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. jhc 0.6.1. John Meacham [5]announced the release of [6]jhc 0.6.1, featuring a a much simplified cross-compilation mechanism. X Haskell Bindings 0.3. Antoine Latter [7]announced the 0.3.* series release of the [8]X Haskell Bindings. This release, like the prior 0.2.* series focuses on making the API prettier. happstack-0.3.2. Matthew Elder [9]announced the release of [10]happstack-0.3.2, with many changes, updates, and bug fixes. sendfile-0.1. Matthew Elder [11]announced the release of [12]sendfile, a library which exposes zero-copy sendfile functionality in a portable way. Right now it natively supports linux 2.6+ (maybe older too) and windows 2000+; on other platforms it will fall back seamlessly to a portable haskell implementation. Reusable Corecursive Queues via Continuations. Leon Smith [13]requested feedback on a draft of an upcoming article in Monad.Reader issue 14, "Lloyd Allison's Corecursive Queues: Why Continuations Matter", describing the implementation of the [14]control-monad-queue package. Haskell on the iPhone. Ryan Trinkle [15]announced that his company, iPwn Studios Inc., is currently preparing to release an open source patch to GHC that allows it to output binaries for iPhone OS. The patch will be released under a BSD license as soon as possible and hopefully integrated into the GHC main-line in the near future. Program to set the GNOME desktop background picture randomly. Colin Paul Adams [16]announced [17]gnome-desktop, a library which periodically picks a random picture from $HOME/Pictures, and sets it as the GNOME desktop background. loli: a minimal web dev DSL. Jinjing Wang [18]announced the release of [19]loli, a web development DSL built on top of [20]hack. It allows you to easily define routes, build your custom template backends through a simple Template interface, and integrate with other hack middleware. Cal3D animation library. Gregory D. Weber [21]announced the [22]Cal3D for Haskell project, which provides a partial binding to the [23]C++ Cal3D animation library, a platform- and graphics-API-independent C++ library for skeletal-based character animation. There are three packages available on hackage: [24]cal3d-0.1, a Haskell binding to the Cal3D library itself; as well as [25]cal3d-opengl-0.1 and [26]cal3d-examples-0.1. A Reader Monad Tutorial. Henry Laxen [27]announced a nice [28]Reader monad tutorial. full-sessions: yet another implementation of session types. Keigo Imai [29]announced the pre-release of [30]full-sessions, yet another implementation of session types in Haskell. Session types are used to statically check the safe and consistent use of communication channels according to protocols. A notable advantage of [31]this implementation is that it requires almost no type annotation or term annotations. and at the same time provides full functionality of session types including channel-generation and channel-passing. darcs 2.3 beta 1. Petr Rockai [32]announced the immediate availability of a first beta release of darcs 2.3. There are a number of improvements and bugfixes over the last stable release, 2.2 (see the announcement for a full list). Moreover, work has been done on performance of "darcs whatsnew" for large repositories. This has also introduced a slight risk of regressions, but please note that all of the disruptive changes are in read-only code paths: the new code will never touch your repository, so it is unable to cause permanent harm. The worst that could happen is that you get no or bad diff from "darcs whatsnew". Please help test it (cabal install [33]darcs-beta)! New release of ZeroTH. Robin Green [34]announced a new release (2009.6.23.3) of [35]ZeroTH, a tool for preprocessing Haskell code to run splices and remove Template Haskell dependencies. Major changes include support for more Haskell code via haskell-src-exts 1.0.0, better error messages, and librification. Emping-0.6 and Tests/Examples. Hans van Thiel [36]announced version 0.6 of [37]Emping, a (prototype) interactive tool for the discovery and analysis of (universal, not statistical) predictive rules in tables of nominal data. haskell-src-exts-1.0.0. Niklas Broberg [38]announced the first stable release of the [39]haskell-src-exts package, version 1.0.0! 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. HaRe (the Haskell Refactorer) in action - short screencast. Claus Reinke [40]linked to [41]a short video showing [42]HaRe, the Haskell refactorer, in action. HaRe still exists---but needs some love in the form of time and/or funding for maintenance and continued development. Trivial pivoting for the DSP lu decomposition. Fernan Bolando [43]announced the beginnings of a [44]simple circuit simulator using haskell, which uses a modified version of the haskell DSP library matrix, extended with a simple pivoting method. Discussion make some Applicative functions into methods, and split off Data.Functor. Ross Paterson [45]proposed moving several functions such as (<$), (*>), and so on into their respective classes with default definitions, to allow for specialized implementations. base library and GHC 6.12. Ian Lynagh began a [46]discussion about how to structure the base library in the future. Proposal: ExplicitForall. Niklas Broberg [47]proposed adding a new GHC extension, ExplicitForall, to be used for turning on explicit 'forall' syntax in types, and to help disentangle and simplify some existing extensions. Generic Graph Class. Ivan Lazar Miljenovic [48]proposed a generic graph class to serve as a common interface for the many Haskell libraries that deal with graph data structures. Type system trickery. Andrew Coppin [49]asked how to statically ensure certain properties of recursive data structures with the type system, generating varied suggestions involving GADTs. Blog noise [50]Haskell news from the [51]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * Magnus Therning: [52]Making a choice from a list in Haskell, Vty (part 0). * The Gentoo Haskell Team: [53]Haskell in Gentoo. * Michael Snoyman: [54]Hack Introduction. * >>> Henry Laxen: [55]Reader Monad Confusion. * >>> Akshay: [56]Dynamic Programming in Haskell and why DP is useful. * David Amos: [57]Direct products revisited. * mightybyte: [58]Basic Happstack Blog App. * David Amos: [59]Some groups and some graphs. * Gergely Patai: [60]Short-term hp2any plans. * Isaac Dupree: [61]cross-package, Plan A. * >>> Oliver Reeves: [62]Data Crunching in Haskell. * Roman Cheplyaka: [63]Halting problem. * Petr Rockai: [64]darcs 2.3 beta 1. * Eric Kow (kowey): [65]Haskell syntax highlighting on Wikipedia and Wikibooks. * Greg Bacon: [66]Setting up a simple test with Cabal. * Isaac Dupree: [67]Cross-package documentation, part 1. * Sean Leather: [68]RFC: Extensible, typed scanf- and printf-like functions for Haskell. * >>> Akshay: [69]Foray Into Haskell. * >>> Ivan Uemlianin: [70]decorate-sort-undecorate in Haskell. * Isaac Dupree: [71]How To Navigate Your Code:. * Petr Rockai: [72]soc progress 5. * DEFUN 2009: [73]The tutorial schedule is now ready. * DEFUN 2009: [74]Last call for talk proposals!. * >>> Greg Bacon: [75]Setting up a simple test with Cabal. * The GHC Team: [76]New paper: Parallel Performance Tuning for Haskell. * Brandon Simmons: [77]Fun with Lazy Arrays: the LZ77 Algorithm. * >>> Keith: [78]Bird Tracks Through Math Land: Basic Matrix Ops. Quotes of the Week * gnuvince: Contributions to Hackage are measured in ?Conals. * DavidWheeler: Compatibility means deliberately repeating other people's mistakes. About the Haskell Weekly News New editions are posted to [79]the Haskell mailing list as well as to [80]the Haskell Sequence and [81]Planet Haskell. [82]RSS is also available, and headlines appear on [83]haskell.org. To help create new editions of this newsletter, please see the information on [84]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [85]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.general/17320 3. http://www.regmaster.com/conf/icfp2009.html 4. http://haskell.org/haskell-symposium/2009/ 5. http://www.haskell.org//pipermail/haskell/2009-June/021449.html 6. http://repetae.net/computer/jhc/ 7. http://www.haskell.org//pipermail/haskell/2009-June/021460.html 8. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhb 9. http://article.gmane.org/gmane.comp.lang.haskell.general/17317 10. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happstack 11. http://article.gmane.org/gmane.comp.lang.haskell.general/17316 12. http://hackage.haskell.org/package/sendfile 13. http://article.gmane.org/gmane.comp.lang.haskell.general/17311 14. http://hackage.haskell.org/package/control-monad-queue 15. http://article.gmane.org/gmane.comp.lang.haskell.general/17307 16. http://article.gmane.org/gmane.comp.lang.haskell.general/17304 17. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gnome%2Ddesktop 18. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60675 19. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/loli 20. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hack 21. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60596 22. http://haskell.org/haskellwiki/Cal3d_animation 23. http://home.gna.org/cal3d/ 24. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cal3d 25. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cal3d%2Dopengl 26. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cal3d%2Dexamples 27. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60591 28. http://www.maztravel.com/haskell/readerMonad.html 29. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60511 30. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/full%2Dsessions 31. http://www.agusa.i.is.nagoya-u.ac.jp/person/sydney/full-sessions.html 32. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60465 33. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/darcs%2Dbeta 34. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60430 35. http://hackage.haskell.org/package/zeroth 36. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60411 37. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Emping 38. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60392 39. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell%2Dsrc%2Dexts 40. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60388 41. http://www.youtube.com/watch?v=4I7VZV7elnY 42. http://www.cs.kent.ac.uk/projects/refactor-fp/ 43. http://article.gmane.org/gmane.comp.lang.haskell.cafe/60590 44. http://plan9.bell-labs.com/sources/contrib/fernan/escomma.tar.bz2 45. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/11428 46. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/11413 47. http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/17137 48. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/60460 49. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/60277 50. http://planet.haskell.org/ 51. http://haskell.org/haskellwiki/Blog_articles 52. http://therning.org/magnus/archives/664 53. http://gentoohaskell.wordpress.com/?p=3 54. http://blog.snoyman.com/2009/06/28/hack-introduction/ 55. http://www.maztravel.com/haskell/readerMonad.html 56. http://www.akrish.net/2009/06/28/dynamic-programming-in-haskell-and-why-dp-is-useful/ 57. http://haskellformaths.blogspot.com/2009/06/direct-products-revisited.html 58. http://softwaresimply.blogspot.com/2009/04/basic-happstack-blog-app.html 59. http://haskellformaths.blogspot.com/2009/06/some-groups-and-some-graphs.html 60. http://just-bottom.blogspot.com/2009/06/short-term-hp2any-plans.html 61. http://haddock2009.wordpress.com/2009/06/25/cross-package-plan-a/ 62. http://buffered.io/2009/06/25/data-crunching-in-haskell/ 63. http://ro-che.blogspot.com/2009/06/halting-problem.html 64. http://web.mornfall.net/blog/darcs_2.3_beta_1.html 65. http://koweycode.blogspot.com/2009/06/haskell-syntax-highlighting-on.html 66. http://feedproxy.google.com/~r/gbacon/~3/7rlf4Dd1JKU/setting-up-simple-test-with-cabal.html 67. http://haddock2009.wordpress.com/2009/06/24/cross-package-documentation-part-1/ 68. http://feedproxy.google.com/~r/splonderzoek/~3/vO9VuXrFTCg/rfc-extensible-typed-scanf-and-printf.html 69. http://www.akrish.net/2009/06/24/foray-into-haskell/ 70. http://llaisdy.wordpress.com/2009/06/24/decorate-sort-undecorate-in-haskell/ 71. http://haddock2009.wordpress.com/2009/06/23/how-to-navigate-your-code/ 72. http://web.mornfall.net/blog/soc_progress_5.html 73. http://www.defun2009.info/blog/2009/06/the-tutorial-schedule-is-now-ready/ 74. http://www.defun2009.info/blog/2009/06/last-call-for-talk-proposals/ 75. http://gbacon.blogspot.com/2009/06/setting-up-simple-test-with-cabal.html 76. http://ghcmutterings.wordpress.com/2009/06/22/new-paper-parallel-performance-tuning-for-haskell/ 77. http://coder.bsimmons.name/blog/2009/06/fun-with-lazy-arrays-the-lz77-algorithm/ 78. http://blog.keithsheppard.name/2009/06/bird-tracks-through-math-land-basic.html 79. http://www.haskell.org/mailman/listinfo/haskell 80. http://sequence.complete.org/ 81. http://planet.haskell.org/ 82. http://sequence.complete.org/node/feed 83. http://haskell.org/ 84. http://haskell.org/haskellwiki/HWN 85. http://code.haskell.org/~byorgey/code/hwn/ From pds at di.uevora.pt Mon Jun 29 17:01:06 2009 From: pds at di.uevora.pt (Pedro Salgueiro) Date: Mon Jun 29 16:43:34 2009 Subject: [Haskell] INAP 2009: DEADLINE EXTENSION and Final Call for Papers Message-ID: <1246309266.4038.56.camel@rebirth> ------------------------------------------------------------------- (PLEASE DISTRIBUTE -- **DEADLINE EXTENDED** -- PLEASE DISTRIBUTE) ------------------------------------------------------------------- Final Call for Papers INAP 2009 18th International Conference on Applications of Declarative Programming and Knowledge Management November 5-7, 2009 Evora, Portugal http://www.di.uevora.pt/inap2009/ http://inap.dialogengines.com/ ------------------------------------------------------------ Organized by the Portuguese AI Society (APPIA), the INAP Committee and the Society of Logic Programming (GLP e.V.) == Overview == Declarative Programming is a family of advanced paradigms for the modeling and solving of complex problems. These specification and implementation methods have attracted more and more attention over the past years, e.g. in the domains of databases and natural language processing, for modeling and the processing of combinatorial problems, and for establishing systems for the web. == INAP 2009 == INAP is a communicative and dense forum for intensive discussion of applications of important technologies related to Prolog, Logic and Constraint Programming as well as closely related advanced software. It comprehensively covers the impact of programmable logic solvers in the Internet Society, its underlying technologies, and leading edge applications in industry, commerce, government, and societal services. INAP 2009 continues a tradition of successful workshops cast around the applications of declarative programming, which were held in Kobe (1997), Tokyo (1995, 1996, 1998 - 2001), Potsdam (2004), Fukuoka (2005) and Wuerzburg (2007). We invite the submission of high quality papers on the described topics, especially, but not exclusively, on different aspects of Declarative Programming, Constraint Processing and Knowledge Management as well as their use for Distributed Systems and the Web: - Knowledge Management, e.g. Data Mining, Decision Support, Deductive Databases - Distributed Systems and the Web, e.g. Agents and Concurrent Engineering, Semantic Web - Constraints, e.g. Constraint Systems, Extensions of Constraint (Logic) Programming - Theoretical Foundations, e.g. Deductive Databases, Nonmonotonic Reasoning - Systems and Tools for Academic and Industrial Use - Knowledge-based Web Services - Logic Solvers and Applications == Workshop Format == The technical program of the workshop will include invited presentations (to be announced), regular technical sessions with presentations of the accepted papers, system demonstrations and a panel discussion. == Conference Venue == The conference will be held at the University of Evora, Portugal in November 5-7, 2009. Evora is a nice and quiet historical city located in the south of Portugal that can be reached from Lisbon by train or coach in under 2 hours. It is a small city of 60.000 inhabitants, 120 km inland from Lisbon and classified by Unesco as World Heritage. The University of Evora was established in the 16th Century and is the 2nd oldest Portuguese University. The social program is promising since the region is very rich in historical sites (Stone Age, Roman, Medieval and Renaissance remains) and also offers a very special gastronomy. See http://en.wikipedia.org/wiki/%C3%89vora for more information. == Important Dates == Paper Submission Deadline: July 13, 2009 (EXTENDED!) Notifications to Authors: August 17, 2009 Camera-ready Version Deadline: September 14, 2009 INAP 2009 Workshop: November 5-7, 2009 == Submission Guidelines == Participants should submit a paper (maximum 15 pages, PDF format), describing their work in topics relevant to the workshop. Accepted papers will be presented during the workshop. At least one author of an accepted contribution is expected to register for the workshop, and present the paper. All submissions should include the author's name(s), affiliation, complete mailing address, and email address. Authors are requested to prepare their submissions, following the LNCS/LNAI Springer format. Please see: http://www.springer.de/comp/lncs/authors.html for further details. The submission should be submitted through the electronic submission site: http://www.easychair.org/conferences/?conf=inap2009 The deadline for receipt of submissions is July 13, 2009. Papers received after this date will not be reviewed. Eligible papers will be peer-reviewed by at least three members of the Program Committee. Authors will be notified via email of the results by August 17, 2009. Authors of accepted papers are expected to improve their paper based on reviewers' comments and to send a camera ready version of their manuscripts by September 14, 2009. Accepted papers will be included in the workshop proceedings, which will be distributed to the participants. As in previous editions, we plan to publish selected papers in a proceedings volume in the Springer Lecture Notes in Artificial Intelligence (LNAI) series. == Organizing Committee == Vitor Nogueira vbn AT di.uevora.pt Salvador Abreu spa AT di.uevora.pt Pedro Salgueiro pds AT di.uevora.pt Universidade de Evora Portugal == Program Committee == Salvador Abreu, University of Evora, Portugal (co-chair) Sergio Alvarez, Boston College, USA Philippe Codognet, CNRS/JFLI, Tokyo, Japan Vitor Santos Costa, University of Porto, Portugal Daniel Diaz, University of Paris I, France Ulrich Geske, University of Potsdam, Germany Gopal Gupta, UT Dallas, USA Petra Hofstedt, Technical University of Berlin, Germany Ulrich Neumerkel, Technical University of Vienna, Austria Vitor Nogueira, University of Evora, Portugal Enrico Pontelli, New Mexico State University, USA Irene Rodrigues, University of Evora, Portugal Carolina Ruiz, Worcester Polytechnic Institute, USA Dietmar Seipel, University of Wuerzburg, Germany (co-chair) Terrance Swift, CENTRIA, Portugal Hans Tompits, Technical University of Vienna, Austria Masanobu Umeda, Kyushu Institute of Technology, Japan Armin Wolf, Fraunhofer FIRST, Berlin, Germany Osamu Yoshie, Waseda University, Japan == Contact Information == inap2009@di.uevora.pt Universidade de Evora Departamento de Informatica Largo dos Colegiais, 2 7004-516 Evora - PORTUGAL From conal at conal.net Mon Jun 29 20:44:02 2009 From: conal at conal.net (Conal Elliott) Date: Mon Jun 29 20:27:06 2009 Subject: [Haskell] ANN: package Boolean: Generalized booleans Message-ID: I just uploaded a new package [1] for generalized booleans, which provides type classes with generalizations of boolean values & operations, if-then-else, Eq and Ord. These values & types come up for me with every new deep DSEL, and I think they do for others as well. The design space has some tricky trade-offs, and I'm not positive I've found the optimum yet. Users & comments are very welcome. Please direct discussion to the haskell-cafe list (rather than haskell list). [1]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Boolean - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090629/0796a5ed/attachment.html From kfisher at research.att.com Tue Jun 30 22:06:30 2009 From: kfisher at research.att.com (Kathleen Fisher) Date: Tue Jun 30 21:49:09 2009 Subject: [Haskell] Call for Participation: CUFP Message-ID: <8F4D1129-97D3-48B5-9189-C913B1B6DD87@research.att.com> Commercial Users of Functional Programming Workshop (CUFP) 2009 Functional Programming As a Means, Not an End Call for Participation Sponsored by SIGPLAN Co-located with ICFP 2009 _________________________________________________________ 4 September 2009 Edinburgh, Scotland Registration is through http://www.regmaster.com/conf/icfp2009.html _________________________________________________________ Functional languages have been under academic development for over 25 years, and remain fertile ground for programming language research. Recently, however, developers in industrial, governmental, and open source projects have begun to use functional programming successfully in practical applications. In these settings, functional programming has often provided dramatic leverage, including whole new ways of thinking about the original problem. The goal of the CUFP workshop is to act as a voice for these users of functional programming. The workshop supports the increasing viability of functional programming in the commercial, governmental, and open-source space by providing a forum for professionals to share their experiences and ideas, whether those ideas are related to business, management, or engineering. The workshop is also designed to enable the formation and reinforcement of relationships that further the commercial use of functional programming. Providing user feedback to language designers and implementors is not a primary goal of the workshop, though it will be welcome if it occurs. Program CUFP 2009 will last a full day and feature a discussion session and the following presentations: Bryan O'Sullivan Keynote: Real world Haskell Lee Momtahan (EDF Trading) Implementing a Domain-Specific Language for Derivative Pricing with Scala Bhasker Kode (hover.in) Erlang at hover.in Jefferson Heard, (Renaissance Computing Institute) Teleconferencing over High-res Maps with Haskell Alex Peake (TFC) and Adam Granicz (Intellifactory) The First Substantial Line of Business Application in F# Christopher Piro and Eugene Letuchy (Facebook) Functional Programming at Facebook Fermin Reig (Morgan Stanly) Computing with Time Series Data in Finance Warren Harris (Metaweb) Functional Programming at Freebase Mark Wong-VanHaren (Glyde) Clear & Simple: Composing a Marketplace Duncan Coutts (Well-Typed) Birth of the Industrial Haskell Group There will be no published proceedings, as the meeting is intended to be more a discussion forum than a technical interchange. See http://cufp.galois.com for more information, including presentation abstracts and the most recent schedule information. This will be the sixth CUFP; see CUFP 2004 CUFP 2005, CUFP 2006, CUFP 2007 and CUFP 2008 for information about the earlier meetings, including reports from attendees and video of the most recent talks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20090630/3d2e4518/attachment.html