Re: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?
On Sun, Jun 6, 2010 at 5:10 AM, Thomas Hartman tphya...@gmail.com wrote: Here's two implementations of break, a snappy one from the prelude, ... prelbreak p xs = (takeWhile (not . p) xs,dropWhile (not . p) xs) -- fast, more or less as implemented in prelude iiuc I had a look at the prelude, and I was surprised to see there's 2 versions, depending on a flag : #ifdef USE_REPORT_PRELUDE break p = span (not . p) #else -- HBC version (stolen) break _ x...@[] = (xs, xs) break p xs@(x:xs') | p x= ([],xs) | otherwise = let (ys,zs) = break p xs' in (x:ys,zs) #endif I'm curious why is it so, and which version is compiled in the platform or the ghc binaries. ( my guess is USE_REPORT_PRELUDE compiles functions as defined in the haskell report, but the other version is faster and used by default. ) David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Haddock on HP failing
Sorry, I should have said. I have installed Haskell Platform in the default place: C:\Program Files\Haskell Platform\2010.1.0.0 Chris -Original Message- From: Ivan Lazar Miljenovic [mailto:ivan.miljeno...@gmail.com] Sent: 07 June 2010 23:35 To: Chris Dornan Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Haddock on HP failing Chris Dornan ch...@chrisdornan.com writes: I am trying to use Haddock on the Haskell Platform 2010.1.0.0 and getting haddock.exe: can't find a package database at E:\ghc\ghc-6.12.1\lib\package.conf.d Where did you install GHC to (just checking...)? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] HP/Cygwin and Curl
Thanks very much: I didn't know about this resource. I do appreciate all of the hard work everyone has put in and I want to contribute myself, especially in 2011 (I am fully committed until then). For the moment the best contribution I can make is to report the problems I am having. The above wiki page is (of course) too vague about how Cygwin and MSYS can be used. Cygwin is a much better supported product and a much easier way of getting hold of many Unixy things (like X11). AFAIK MSYS doesn't have a proper installer at the moment. It would be nice to know how Cygwin can be used with HP. If the answer is not at all (for serious work) then can we say this very prominently on HP Windows page. How about linking the HP-Windows page to the Wiki article on Haskell for Windows? A FAQ for HP would also surely be useful. If others agree these would be useful and they haven't been when I will pick them up, but first, are these a good idea? My feeling is that the ramp onto Haskell is far steeper than it needs to be considering the fundamental excellence of the parts. Chris -Original Message- From: Henk-Jan van Tuyl [mailto:hjgt...@chello.nl] Sent: 07 June 2010 22:28 To: Chris Dornan Cc: Haskell-Cafe@haskell.org Subject: Re: [Haskell-cafe] HP/Cygwin and Curl On Mon, 07 Jun 2010 21:44:13 +0200, Chris Dornan ch...@chrisdornan.com wrote: Thanks ever so much for your clear answer. I have no problem at all with using MSYS to build libraries that link to libraries built in Windows land--this seems entirely reasonable. Is this written down somewhere? I mean I really would like to RTFM! :-) Some information can be found at: http://www.haskell.org/haskellwiki/Windows#Tools_for_compilation (improvements are welcome) Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stone age programming for space age hardware?
Hi, The real reason behind my surprise was, that I was wondering how more modern languages could make inroads into such an environment. Haskell without recursion and dynamic memory allocation? Hard to imagine. for some safety critical applications that require certification, SCADE with the underlying Lustre language is used. It has formal semantics and some properties can be checked with automatic verification (up to linear arithmetic). The Lustre dataflow programs are then transformed to C (or Ada), by compiling to automata and representing those in C. This transformation is realized in Ocaml afaik. I think these kind of transformations, maybe specifying an embedded DSL instead of using a language like Lustre resulting in C with static bounds etc. could be a way to use Haskell. But anything using dynamic memory allocation, GC etc. is dangerous for real-time bounds. These programs also often run on old outdated, but reliable HW for which mainly C compilers exist. The used standards only allow a certain set of programming languages (or subsets of these languages) and you even have to use proved and tested compilers and tools. I have a hunch that the real restrictions of this kind of software are not concerned with fixed memory, iterations, whatever, but rather with guaranteed bounds. If that is indeed the case, how feasible would it be to prove relevant properties for systems programmed in Haskell? I think proving the correct transformation of some input language to static C using Haskell is possible. Functional languages like Haskell or Ocaml in the case of SCADE are well suited to this, due to lack of loops, side effects etc. I think atom is such a DSL embedded into Haskell that can generate code for real-time systems. regards Matthias ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
R J wrote: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? f = map head . takeWhile (not . null) . iterate (drop 2) . drop 1 Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PDF generation?
The fonts aren't rasterized, but PDFs that were converted from PS tend to look awful in almost any PDF viewer other than Adobe's Acrobat Reader. Fonts look especially bad. I don't know exactly what the problem is, but my experience is that you are best off generating PDF directly, and using Acrobat Reader on any document that looks bad otherwise. Not to mention that PDF has a document model and supports things such as hyperlinks, which Postscript does not, which is another reason to avoid PostScript. Best, Leon On Tue, Jun 1, 2010 at 2:45 PM, Yitzchak Gale g...@sefer.org wrote: I wrote: I have often generated PostScript from Haskell... Then you convert the PS to PDF using any of the nice utilities around for that Pierre-Etienne Meunier wrote: Isn't there a problem with non-type 1 vectorial fonts being rasterized during this conversion ? No. PDF is just a simplified, compressed encoding of PostScript. Unless there is some special reason to do so, why would a conversion utility go to the trouble of rasterizing fonts instead of just copying them in? Perhaps something like ImageMagick might do that; its internal format is a raster. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: [Gtk2hs-users] Installation problem with cairo.
Hi, I cannot subscribe to libraries maillist. So I forward this here. I cannot install gtk2hs-cairo by cabal using cairo 1.9.6 compiled myself. Cabal always said that the cairo library/devel files were missing. -- Forwarded message -- From: Axel Simon axel.si...@in.tum.de Date: Tue, Jun 8, 2010 at 7:15 PM Subject: Re: [Gtk2hs-users] Installation problem with cairo. To: Magicloud Magiclouds magicloud.magiclo...@gmail.com Cc: gtk2hs-users gtk2hs-us...@lists.sourceforge.net Hi again, it's very difficult for me to say what is happening. Could you ask on the cabal mailing list to see if anybody there has an idea. Cheers, Axel On 08.06.2010, at 11:01, Magicloud Magiclouds wrote: I've tried a little, the error was not thrown out in gtk2hssetup.hs. And even I faked a version (1.8.10), it did not work. On Tue, Jun 8, 2010 at 3:47 PM, Axel Simon axel.si...@in.tum.de wrote: Hi, On Jun 8, 2010, at 9:21, Magicloud Magiclouds wrote: Yes, seems like so. Here is the output: # /usr/bin/pkg-config --modversion cairo-pdf 1.9.6 # /usr/bin/pkg-config --modversion cairo-ps 1.9.6 # /usr/bin/pkg-config --modversion cairo-svg 1.9.6 # /usr/bin/pkg-config --modversion cairo 1.9.6 Oh dear. Since cabal manages once to get the correct version and fails later on, I assume it's the magic Duncan added to out Gtk2HsSetup.hs file that requests the package version again. If you look for --FIXME: Cabal should tell us the selected pkg-config package versions in the -- LocalBuildInfo or equivalent. -- In the mean time, ask pkg-config again. in the cabal file and try to add some debugging output then maybe you can find out more. I suspect that either the LocalBuildInfo or the PackageDescription value is not the most up-to-date one but some default value that lack some path or some such. cheers, Axel On Tue, Jun 8, 2010 at 2:56 PM, Axel Simon axel.si...@in.tum.de wrote: Hi, On Jun 8, 2010, at 8:54, Magicloud Magiclouds wrote: /usr/bin/pkg-config --modversion cairo setup: Missing dependency on a foreign library: * Missing C library: cairo This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. well, what's the output of /usr/bin/pkg-config --modversion cairo ? Maybe cabal fails to parse the version for some reason. Axel -- 竹密岂妨流水过 山高哪阻野云飞 -- 竹密岂妨流水过 山高哪阻野云飞 -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
Can't forget fix in a game of code golf! (fix $ \f (x:_: xs) - x : f xs) [1..] = [1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,4... 2010/6/8 Yitzchak Gale g...@sefer.org: R J wrote: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? f = map head . takeWhile (not . null) . iterate (drop 2) . drop 1 Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function to find a substring
R J wrote: What's an elegant definition of a Haskell function that takes two strings and returns Nothing in case the first string isn't a substring of the first, or Just i, where i is the index number of the position within the first string where the second string begins? Thomas Hartman wrote: If you want to use libs to make your life easier, maybe something along these lines? Prelude Data.List.Split Safe ... True, those are both very nice libraries. It's just about as easy to do this with the more standard ones, though: Prelude Data.List Data.Maybe listToMaybe . map fst . filter ((asdf `isPrefixOf`) . snd) . zip [0..] . tails $ blee blah asdf bloo Just 10 Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?
This isn`t a manifestation of the Curry-Howard isomorphism? 2010/6/8 Alexander Solla a...@2piix.com On Jun 7, 2010, at 4:10 PM, Alexander Solla wrote: You might note how much like evaluating the function generating the analysis is. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?
Hello David, Tuesday, June 8, 2010, 10:33:51 AM, you wrote: ( my guess is USE_REPORT_PRELUDE compiles functions as defined in the haskell report, but the other version is faster and used by default. ) you are right -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
if we add 'a' to the definition of this function, (to make it work), the type of it turns out to be: [a] - [(a, Bool)] you might have forgotten the map fst $ part. Best, On 8 June 2010 14:51, Bill Atkins watk...@alum.rpi.edu wrote: f :: [a] - [a] f = filter snd $ zip a (cycle [True, False]) On Monday, June 7, 2010, Ozgur Akgun ozgurak...@gmail.com wrote: or, since you don't need to give a name to the second element of the list: f :: [a] - [a] f (x:_:xs) = x : f xsf x = x On 7 June 2010 20:11, Ozgur Akgun ozgurak...@gmail.com wrote: i think explicit recursion is quite clean? f :: [a] - [a]f (x:y:zs) = x : f zs f x = x On 7 June 2010 19:42, Thomas Hartman tphya...@gmail.com wrote: maybe this? map snd . filter (odd . fst) . zip [1,2..] $ [1,2,3,4,5] 2010/6/6 R J rj248...@hotmail.com: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get started. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ozgur Akgun -- Ozgur Akgun -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
f :: [a] - [a] f = filter snd $ zip a (cycle [True, False]) On Monday, June 7, 2010, Ozgur Akgun ozgurak...@gmail.com wrote: or, since you don't need to give a name to the second element of the list: f :: [a] - [a] f (x:_:xs) = x : f xsf x = x On 7 June 2010 20:11, Ozgur Akgun ozgurak...@gmail.com wrote: i think explicit recursion is quite clean? f :: [a] - [a]f (x:y:zs) = x : f zs f x = x On 7 June 2010 19:42, Thomas Hartman tphya...@gmail.com wrote: maybe this? map snd . filter (odd . fst) . zip [1,2..] $ [1,2,3,4,5] 2010/6/6 R J rj248...@hotmail.com: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get started. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ozgur Akgun -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: package naming policy (was: Please check your dependencies on fgl)
From: Don Stewart d...@galois.com ivan.miljenovic: Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. How about you give the library a different name then -- so as not to break all those programs? A complete rewrite with a new maintainer: fgl-awesome I would like to argue against this practice, i.e. re-naming new, incompatible versions of existing packages. I think it's bad for the following reasons: 1. It makes development by new users more difficult by fracturing the package-space (the Which version of QuickCheck should I use? problem). Since this is already an acknowledged issue, I think it's better that developers not add to it. 2. It discourages adoption of the latest version despite any benefits the later version may provide. This also leads to greater incompatibility between dependent packages. 3. For packages in the platform, I believe this will create uncertainty about which package(s) should be included with new major releases. 4. It adds to the maintainer workload as the same person or team will often be responsible for both packages. I do agree that there are legitimate reasons why users may decide to remain with older versions, however I think that in nearly all cases the proper solution is to follow the PVP and for users to include upper dependency bounds in .cabal files. In particular, for the very common case of compatibility with older code, an upper dependency bound seems like the correct approach. IMHO changing a package name should be for when developers intend to continue development (not just maintenance releases) along both branches. My 2 cents, anyway. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Function to find a substring
What's an elegant definition of a Haskell function that takes two strings and returns Nothing in case the first string isn't a substring of the first, or Just i, where i is the index number of the position within the first string where the second string begins? my quick take, with Maybe and fmap : substringP :: String - String - Maybe Int substringP _ [] = Nothing substringP sub str = case isPrefixOf sub str of False - fmap (+1) $ substringP sub (tail str) True - Just 0 -- Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: package naming policy (was: Please check your dependencies on fgl)
jwlato: From: Don Stewart d...@galois.com ivan.miljenovic: Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. How about you give the library a different name then -- so as not to break all those programs? A complete rewrite with a new maintainer: fgl-awesome I would like to argue against this practice, i.e. re-naming new, incompatible versions of existing packages. I think it's bad for the following reasons: 1. It makes development by new users more difficult by fracturing the package-space (the Which version of QuickCheck should I use? problem). Since this is already an acknowledged issue, I think it's better that developers not add to it. 2. It discourages adoption of the latest version despite any benefits the later version may provide. This also leads to greater incompatibility between dependent packages. 3. For packages in the platform, I believe this will create uncertainty about which package(s) should be included with new major releases. 4. It adds to the maintainer workload as the same person or team will often be responsible for both packages. I do agree that there are legitimate reasons why users may decide to remain with older versions, however I think that in nearly all cases the proper solution is to follow the PVP and for users to include upper dependency bounds in .cabal files. In particular, for the very common case of compatibility with older code, an upper dependency bound seems like the correct approach. IMHO changing a package name should be for when developers intend to continue development (not just maintenance releases) along both branches. Great points: I've added them to this wiki page of for and against points: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename Please add points as you see fit, and maybe we can come up with a mitigation/change plan. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal problem on OS X
Did you manage to fix this problem, or are there any updates on it? I am now having the same issue - presumably due to updating my Mac OS X version, because cabal was working fine before that. I can't upgrade cabal or install anything either, same reason. Gordon J. Uszkay uszka...@mcmaster.ca On May 22, 2010, at 7:27 AM, Ivan Lazar Miljenovic wrote: Bill Atkins watk...@alum.rpi.edu writes: When I run cabal update on my Mac (Snow Leopard, Intel), I get: % cabal update Downloading the latest package list from hackage.haskell.org cabal: Codec.Compression.Zlib: incompatible zlib version I'm going to randomly guess that the version of the C zlib library that Cabal was indirectly built against is different to the one on your machine. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
And for a few more lines of codes, you get a more flexible solution: data Consume = Take | Skip consumeBy :: [Consume] - [a] - [a] consumeBy [] _ = [] consumeBy _[] = [] consumeBy (tOrS:takesAndSkips) (x:xs) = case tOrS of Take - x : consumeBy takesAndSkips xs Skip - consumeBy takesAndSkips xs *Main consumeBy (cycle [Take,Take,Skip]) [1,2,3,4,5,6] [1,2,4,5] *Main consumeBy (cycle [Take,Take,Take,Skip]) [1,2,3,4,5,6] [1,2,3,5,6] -deech On 6/8/10, Christopher Done chrisd...@googlemail.com wrote: Can't forget fix in a game of code golf! (fix $ \f (x:_: xs) - x : f xs) [1..] = [1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,4... 2010/6/8 Yitzchak Gale g...@sefer.org: R J wrote: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? f = map head . takeWhile (not . null) . iterate (drop 2) . drop 1 Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?
On Tuesday 08 June 2010 08:33:51, David Virebayre wrote: On Sun, Jun 6, 2010 at 5:10 AM, Thomas Hartman tphya...@gmail.com wrote: Here's two implementations of break, a snappy one from the prelude, ... prelbreak p xs = (takeWhile (not . p) xs,dropWhile (not . p) xs) -- fast, more or less as implemented in prelude iiuc I had a look at the prelude, and I was surprised to see there's 2 versions, depending on a flag : #ifdef USE_REPORT_PRELUDE break p = span (not . p) #else -- HBC version (stolen) break _ x...@[] = (xs, xs) break p xs@(x:xs') | p x= ([],xs) | otherwise = let (ys,zs) = break p xs' in (x:ys,zs) #endif I'm curious why is it so, and which version is compiled in the platform or the ghc binaries. ( my guess is USE_REPORT_PRELUDE compiles functions as defined in the haskell report, but the other version is faster and used by default. ) Aye. I'm not sure whether there's a difference with -O2, but it's substantial without optimisations. David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
There have been a few cases of major API / rewrites to famous old packages causing problems, including: * QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL a similar opportunity is present with 'fgl', where the new maintainers are seeking to improve the code. Below I try to summarise the pros and cons of calling the new rewrite/api 'fgl', in the hope we can identify a path that minimizes disruption to users. A group of developers is planning to write a new graph library for Haskell. * They maintain an existing package called 'fgl'. * 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/ * The new library will have different authors and a different API. * They would like the new library 'fgl'. It is a controversial step to write a new library and give it the same name as an existing, famous library. Let's look at the arguments. = Reasons to use the new name = * The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption. * Rewrites are effective if the name is preserved. E.g. QuickCheck 2. * It is the maintainer's right to modify APIs as they see fit. * Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade. * Relatively few packages use fgl. So damage is limited. = Reasons not to use the name = * Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct * Doesn't matter if the old fgl is still around. If the new code is better, it will be adopted on its own merits (see e.g. bytestrings vs packedstring, vector vs uvector) Let the market decide if it is better, rather than forcing us. * The package has been stable for ~10 years -- why change a stable API? It is already perfect * The new package really isn't the same package in any sense. * Rewrites by new teams damage the brand of famous packages (e.g. parsec 3) * No additional breakages are introduced. * If you weren't maintainer of 'fgl' this rewrite wouldn't even be possible to call 'fgl' -- there's a conflict of interest. * Maintaining Haskell98 compatability. Keep it simple. (See regex-posix's mistakes here) * Distros that support the Haskell Platform will have to keep an old version of fgl around for a long time anyway. Are there any other arguments I'm missing? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: package naming policy (was: Please check your dependencies on fgl)
On Tue, Jun 8, 2010 at 4:13 PM, Don Stewart d...@galois.com wrote: jwlato: From: Don Stewart d...@galois.com ivan.miljenovic: Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. How about you give the library a different name then -- so as not to break all those programs? A complete rewrite with a new maintainer: fgl-awesome I would like to argue against this practice, i.e. re-naming new, incompatible versions of existing packages. I think it's bad for the following reasons: 1. It makes development by new users more difficult by fracturing the package-space (the Which version of QuickCheck should I use? problem). Since this is already an acknowledged issue, I think it's better that developers not add to it. 2. It discourages adoption of the latest version despite any benefits the later version may provide. This also leads to greater incompatibility between dependent packages. 3. For packages in the platform, I believe this will create uncertainty about which package(s) should be included with new major releases. 4. It adds to the maintainer workload as the same person or team will often be responsible for both packages. I do agree that there are legitimate reasons why users may decide to remain with older versions, however I think that in nearly all cases the proper solution is to follow the PVP and for users to include upper dependency bounds in .cabal files. In particular, for the very common case of compatibility with older code, an upper dependency bound seems like the correct approach. IMHO changing a package name should be for when developers intend to continue development (not just maintenance releases) along both branches. Great points: I've added them to this wiki page of for and against points: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename Please add points as you see fit, and maybe we can come up with a mitigation/change plan. Thanks very much; that's a useful page. It highlights some points I hadn't considered, such as when the original author is no longer involved with substantial changes to the code. Hopefully a productive discussion will follow. I don't think a one-size-fits-all approach is appropriate, but it would be nice if the community could come to some common recommendations on this topic. Also, to everyone working on fgl: I certainly don't mean to single out your work as an example, however I think your contributions to this discussion are very helpful as it's a current issue for you. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function to find a substring
Hi, R J wrote: What's an elegant definition of a Haskell function that takes two strings and returns Nothing in case the first string isn't a substring of the first, or Just i, where i is the index number of the position within the first string where the second string begins? The naive algorithm of matching the second string on every position of the first string can be implemented as follows. import Data.List (findIndex, tails) findSubstringIndex text pattern = findIndex (pattern `isPrefixOf`) (tails text) Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
2010/6/6 R J rj248...@hotmail.com: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? f x = [y | (True, y) - zip (cycle [False, True]) x] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HP/Cygwin and Curl
Thanks Stephen--that was related to my original question, about using HP with Cygwin. The answer seems to be No!--you must use MSYS (for real work). The short version: - Cygwin provides commandline tools, compilers and libraries - MSYS provides commandline tools for the MinGW compilers and libraries You can use the commandline tools from either Cygwin or MSYS, but you need to compile and link with the compilers and libraries from MinGW. Cygwin's gcc produces binaries that live in a unix-emulation on top of windows, and depend on a cygwin dll to act as a translator. MinGW's gcc produces native windows binaries. Claus http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/ghci-cygwin.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function to find a substring
El dom, 06-06-2010 a las 15:51 +, R J escribió: What's an elegant definition of a Haskell function that takes two strings and returns Nothing in case the first string isn't a substring of the first, or Just i, where i is the index number of the position within the first string where the second string begins? import Data.List f a b = findIndex (a `isPrefixOf`) (tails b) Jürgen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Execution call graph pruning
Hi, I have a call grah which contains information of the edges in the following format caller callee count (time spent by the caller) === foo bar 10100 xxx yyy 2010 zzz yyy 1010 (I used pintool pintool.org to generate this call graph) Now, the problem is that the graph is huge and it take a long to render using 'dot' or use any visualizing tool. Even if they render, it's too cluttered to be useful. I wanted to prune the graph in such a way that I'd have only the edges corresponding to the top 10% of the time consumers. What would be a good way to do such a thing? Has anyone written some utility that I could use? -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Updates in the regions library
Hi Arie (and others who are interested in the regions library), I would like to let you know that I'm working on a new version of my regions package and its reverse dependencies: regions-monadsfd, regions-monadstf, safer-file-handles, regional-pointers and usb-safe. The major change is that I removed the Resource class: class Resource resource where data Handle resource ∷ * open ∷ resource → IO (Handle resource) close ∷ Handle resource → IO () in favor of a much more simple interface, namely: -- | An 'IO' computation that closes or finalizes a resource. For example -- 'hClose' or 'free'. type CloseAction = IO () -- | A handle to a 'CloseAction' that allows you to duplicate the action to a -- parent region using 'dup'. newtype CloseHandle (r ∷ * → *) -- | Register the 'CloseAction' in the region. When the region terminates all -- registered close actions will be perfomed if they're not duplicated to a -- parent region. register ∷ MonadIO pr ⇒ CloseAction → RegionT s pr (CloseHandle (RegionT s pr)) Here's an example how to use this new interface from my updated regional-pointers package: import qualified Foreign.Marshal.Alloc as FMA -- | A regional handle to memory. This should provide a safer replacement for -- Foreign.Ptr.Ptr data RegionalPtr α (r ∷ * → *) = RegionalPtr (Ptr α) (CloseHandle r) {-| Allocates the given number of bytes and returns a regional pointer to them. This should provide a safer replacement for: Foreign.Marshal.Alloc.mallocBytes. -} mallocBytes ∷ MonadCatchIO pr ⇒ Int → RegionT s pr (RegionalPtr α (RegionT s pr)) mallocBytes size = block $ do ptr ← liftIO $ FMA.mallocBytes size let closeAction = free ptr ch ← register closeAction return $ RegionalPtr ptr ch And here's an example from safer-file-handles: -- | A regional handle to an opened file parameterized by the 'IOMode' in which -- you opened the file and the region in which it was created. data RegionalFileHandle ioMode (r ∷ * → *) = RegionalFileHandle (Handle ioMode) (CloseHandle r) openFile ∷ MonadCatchIO pr ⇒ FilePath → IOMode ioMode → RegionT s pr (RegionalFileHandle ioMode (RegionT s pr)) openFile = openNormal E.openFile -- | Opens a file in binary mode then yields a regional handle to it. This -- provides a safer replacement for System.IO.openBinaryFile. openBinaryFile ∷ MonadCatchIO pr ⇒ FilePath → IOMode ioMode → RegionT s pr (RegionalFileHandle ioMode (RegionT s pr)) openBinaryFile = openNormal E.openBinaryFile openNormal ∷ MonadCatchIO pr ⇒ (FilePath → IOMode ioMode → IO (E.Handle ioMode)) → FilePath → IOMode ioMode → RegionT s pr (RegionalFileHandle ioMode (RegionT s pr)) openNormal open filePath ioMode = block $ do h ← liftIO $ open filePath ioMode let closeAction = sanitizeIOError $ hClose h ch ← register closeAction return $ RegionalFileHandle h ch I haven't released it yet because I need to write some more documentation. However all the repositories contain the new code: darcs get http://code.haskell.org/~basvandijk/code/regions darcs get http://code.haskell.org/~basvandijk/code/regions-monadsfd darcs get http://code.haskell.org/~basvandijk/code/regions-monadstf darcs get http://code.haskell.org/~basvandijk/code/regional-pointers darcs get http://code.haskell.org/~basvandijk/code/safer-file-handles darcs get http://code.haskell.org/~basvandijk/code/usb-safe and some examples: darcs get http://code.haskell.org/~basvandijk/code/usb-safe-examples darcs get http://code.haskell.org/~basvandijk/code/safer-file-handles-examples darcs get http://code.haskell.org/~basvandijk/code/usb-safe-and-safer-file-handles-examples Regards, Bas On Wed, Jun 2, 2010 at 3:13 PM, Bas van Dijk v.dijk@gmail.com wrote: On Wed, Jun 2, 2010 at 2:57 PM, Arie Peterson ar...@xs4all.nl wrote: On Wed, Jun 2, 2010 at 2:28 PM, Bas van Dijk v.dijk@gmail.com wrote: Before answering your questions I would like to make sure I understand your Resource type. When I want to create a memory Resource for example is the following what you have in mind? {-# LANGUAGE Rank2Types #-} -- from base: import Foreign.Ptr ( Ptr ) import Foreign.Marshal.Alloc ( mallocBytes, free ) -- from transformers: import Control.Monad.IO.Class ( liftIO ) -- from MonadCatchIO-transformers: import Control.Monad.CatchIO ( MonadCatchIO, bracket ) newtype Resource cap m = Resource { with :: forall a. (cap - m a) - m a } type Memory m a = Resource (Ptr a) m memory :: MonadCatchIO m = Int - Memory m a memory size = Resource $ bracket (liftIO $ mallocBytes size) (liftIO . free) Yes, exactly. I also create type aliases for resources providing a specific capability. On Wed, 2 Jun 2010 14:45:08 +0200, Bas van Dijk v.dijk@gmail.com wrote:
Re: [Haskell-cafe] Removing alternate items from a list
Yes, this was an old draft I accidentally sent out. My post higher up the thread is correct. :) On Tuesday, June 8, 2010, Ozgur Akgun ozgurak...@gmail.com wrote: if we add 'a' to the definition of this function, (to make it work), the type of it turns out to be: [a] - [(a, Bool)] you might have forgotten the map fst $ part. Best, On 8 June 2010 14:51, Bill Atkins watk...@alum.rpi.edu wrote: f :: [a] - [a] f = filter snd $ zip a (cycle [True, False]) On Monday, June 7, 2010, Ozgur Akgun ozgurak...@gmail.com wrote: or, since you don't need to give a name to the second element of the list: f :: [a] - [a] f (x:_:xs) = x : f xsf x = x On 7 June 2010 20:11, Ozgur Akgun ozgurak...@gmail.com wrote: i think explicit recursion is quite clean? f :: [a] - [a]f (x:y:zs) = x : f zs f x = x On 7 June 2010 19:42, Thomas Hartman tphya...@gmail.com wrote: maybe this? map snd . filter (odd . fst) . zip [1,2..] $ [1,2,3,4,5] 2010/6/6 R J rj248...@hotmail.com: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get started. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ozgur Akgun -- Ozgur Akgun -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
On 8 June 2010 15:13, Jürgen Doser jurgen.do...@gmail.com wrote: El dom, 06-06-2010 a las 14:46 +, R J escribió: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? adding another suggestion: import Data.Either(rights) f = rights . zipWith ($) (cycle [Left,Right]) Ohhh. Nice. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: package naming policy (was: Please check your dependencies on fgl)
jwlato: Great points: I've added them to this wiki page of for and against points: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename Please add points as you see fit, and maybe we can come up with a mitigation/change plan. Thanks very much; that's a useful page. It highlights some points I hadn't considered, such as when the original author is no longer involved with substantial changes to the code. Hopefully a productive discussion will follow. I don't think a one-size-fits-all approach is appropriate, but it would be nice if the community could come to some common recommendations on this topic. Also, to everyone working on fgl: I certainly don't mean to single out your work as an example, however I think your contributions to this discussion are very helpful as it's a current issue for you. Yes, my intent here is to produce a set of guidelines for maintainers of important packages, that ensures we balance stability with innovation. We have a great document for what to consider when adding packages to the HP, for example: http://trac.haskell.org/haskell-platform/wiki/AddingPackages But nothing yet for maintainers who want to keep a package moving along. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
Hello The regular list functionals - map, zip, foldl, foldr, filter, etc. - all process the input list at speed 1 - i.e. one element at a time. As Ozgur Akgun has shown - consuming the list at speed 2 gives a very pleasant implementation - algorithmically: consume at speed 2, produce the new list with the first element of the two and drop the second. Trying to code an algorithm at speed 1 with the list functionals presents a significant hurdle towards clarity of exposition... Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
El dom, 06-06-2010 a las 14:46 +, R J escribió: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? adding another suggestion: import Data.Either(rights) f = rights . zipWith ($) (cycle [Left,Right]) Jürgen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
It only works for infinite lists, though you wanted it :) (fix $ \f xs - case xs of { (x:_: xs) - x : f xs; _ - [] }) [1..10] = [1,3,5,7,9] here you go :) 2010/6/8 Yitzchak Gale g...@sefer.org Christopher Done wrote: Can't forget fix in a game of code golf! (fix $ \f (x:_: xs) - x : f xs) [1..] = [1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,4... Ho, good shot! It only works for infinite lists, though: Prelude (fix $ \f (x:_: xs) - x : f xs) [1..10] [1,3,5,7,9*** Exception: interactive:1:7-30: Non-exhaustive patterns in lambda Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Stone age programming for space age hardware?
Michael Schuerig wrote: I was dumbfounded, although I have known all this. I have no personal experience with either embedded or real time software, but I've been aware that C still is the most popular language for that purpose and that coding standards are very restrictive. The real reason behind my surprise was, that I was wondering how more modern languages could make inroads into such an environment. Haskell without recursion and dynamic memory allocation? Hard to imagine. I have absolutely no experience with real time system, but if I were tasked to write with these coding standards, I would refuse and instead create a small DSL in Haskell that compiles to the requested subset of C. After all, the question is this: why use C if you don't actually use C? The reason is probably that designing/writing a proper DSL is considered too error prone, but with today's theorem provers, this should no longer be the case. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: haskell.org down?
I saw on the Reddit page that people urged caution about the costs of hosting haskell.org commercially. This was a jest wasn't it? ( The cost of webhosting is absurdly cheap, by almost any standards.) I would be very happy to help out here but time (where the true costs lie) is my main concern. If it's still a problem in the new year I will look into it. Seriously--this is unnecessary and harmful. Chris -Original Message- From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Vo Minh Thu Sent: 08 June 2010 04:04 To: Benjamin L. Russell Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Re: haskell.org down? 2010/6/7 Benjamin L. Russell dekudekup...@yahoo.com: Ozgur Akgun ozgurak...@gmail.com writes: http://downforeveryoneorjustme.com/www.haskell.org-- Ozgur Akgun Same problem here since two days ago. Apparently, the server just went back up. Anybody know what kept the server down for so long? http://www.reddit.com/r/haskell/comments/cbkkb/wwwhaskellorg_wiki_mailing_li st_server_has_been/ Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Function to find a substring
R J rj248...@hotmail.com writes: What's an elegant definition of a Haskell function that takes two strings and returns Nothing in case the first string isn't a substring of the first, or Just i, where i is the index number of the position within the first string where the second string begins? f n h = listToMaybe [b | (a,b)- tails h `zip` [1..], n `isPrefixOf` a] seems plausible, but how do you define elegant? -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
Christopher Done wrote: Can't forget fix in a game of code golf! (fix $ \f (x:_: xs) - x : f xs) [1..] = [1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,4... Ho, good shot! It only works for infinite lists, though: Prelude (fix $ \f (x:_: xs) - x : f xs) [1..10] [1,3,5,7,9*** Exception: interactive:1:7-30: Non-exhaustive patterns in lambda Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
OK, here's mine: f as = [ x | (True,x) - zip (cycle [True, False]) as ] -md begin R J quotation: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? _ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons
Hello all While new libraries develop at pace, their documentation rarely does; so I'd have to disagree with John's claim that re-naming libraries makes development by new users harder. I'd argue that having tutorials not work for later revisions is more confusing than having various packages doing the same thing. I'd also contend that beginners are better off lagging behind the cutting edge and using Parsec 2, QuickCheck 1, Haskore-vintage, as the earlier version all have comprehensive documentation - Parsec 2 and Haskore have extensive manual/tutorials, QuickCheck 1 was small enough that the original QuickCheck paper covered its use. An advantage of separate names (both for the package name and module name-space) is that its easier to have both packages installed at the same time - the old one to work with while learning the package, the new one if other installed packages depend on it. This can still be done with package-hiding but its less straight-forward. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons
On 06/08/10 11:08, Don Stewart wrote: Are there any other arguments I'm missing? Also parsec3 had an issue as an upgrade that it was slower at runtime (at least for a few years). (and some people were using parsec in the real world for performance-critical applications.) -Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?
On Jun 8, 2010, at 2:38 AM, Alberto G. Corona wrote: This is`t a manifestation of the Curry-Howard isomorphism? Yes, basically. If we rephrase the isomorphism as a proof is a program, the formula it proves is a type for the program (as Wikipedia states it), we can see the connection. The characterization of prelBreak I gave is a type for prelBreak. The type is richer than we can express in the Haskell type system (prelbreak accepts a proposition p and a list xs, and returns a pair whose first element is the largest prefix of xs for which no x satisfies p, and whose second element is the complement of the first, taken in xs.), but we can still reason about the richer type mathematically, and the Curry-Howard isomorphism applies to it.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart d...@galois.com wrote: (... There have been a few cases of major API / rewrites to famous old packages causing problems, including: * QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL ...) (... * No additional breakages are introduced. ...) Oh lord yes... just call it fgl3 and leave the fgl package alone. This is a source based community here... so you take a package that has a dependency on another library and you go out and get that to cover the dependency and the API is not the same!!! AND especially if that might be the only thing you will ever use that lib for ... and you have to stop and rewrite the original.. and as someone else said with maybe documentation of that API that is not maybe finished or... NO ... At that point the person will probably just DISCARD the compile on the lib or program that had the dependency.. rather then put the effort in to learn an entire API that doesn't match up.. BAD IDEA!! cheers, gene ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Stone age programming for space age hardware?
On Tuesday 08 June 2010, Heinrich Apfelmus wrote: Michael Schuerig wrote: I was dumbfounded, although I have known all this. I have no personal experience with either embedded or real time software, but I've been aware that C still is the most popular language for that purpose and that coding standards are very restrictive. The real reason behind my surprise was, that I was wondering how more modern languages could make inroads into such an environment. Haskell without recursion and dynamic memory allocation? Hard to imagine. I have absolutely no experience with real time system, but if I were tasked to write with these coding standards, I would refuse and instead create a small DSL in Haskell that compiles to the requested subset of C. That suggestion is similar to the approach taken by verifiable languages, as Matthias describes it in a parallel reply. Now, the interesting question is, whether it is possible to define a DSL that's expressive enough and still can be translated to a very restrictive subset of C. I wouldn't expect the on-board functionality of a space probe or rover to be trivial. I think it would count as cheating if you compile down a DSL to C code that only takes a fixed chunk of memory, but then itself manages blocks of that memory dynamically. After all, the question is this: why use C if you don't actually use C? The reason is probably that designing/writing a proper DSL is considered too error prone, but with today's theorem provers, this should no longer be the case. As I understood Holzmann in his talk, use of C is a kind of cultural heritage at JPL. BTW, thanks for your recent video on GADTs. Michael -- Michael Schuerig mailto:mich...@schuerig.de http://www.schuerig.de/michael/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
Or you just put an upper bound on the versions of the fgl library that your program will build against, as you should be doing anyway, and then nothing breaks. Cheers, Greg On Jun 8, 2010, at 11:08 AM, Gene A wrote: On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart d...@galois.com wrote: (... There have been a few cases of major API / rewrites to famous old packages causing problems, including: * QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL ...) (... * No additional breakages are introduced. ...) Oh lord yes... just call it fgl3 and leave the fgl package alone. This is a source based community here... so you take a package that has a dependency on another library and you go out and get that to cover the dependency and the API is not the same!!! AND especially if that might be the only thing you will ever use that lib for ... and you have to stop and rewrite the original.. and as someone else said with maybe documentation of that API that is not maybe finished or... NO ... At that point the person will probably just DISCARD the compile on the lib or program that had the dependency.. rather then put the effort in to learn an entire API that doesn't match up.. BAD IDEA!! cheers, gene ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On Tuesday 08 June 2010 20:21:54, Gregory Crosswhite wrote: Or you just put an upper bound on the versions of the fgl library that your program will build against, as you should be doing anyway, and then nothing breaks. Cheers, Greg Right. At least, nothing breaks until the next compiler release makes the old library break. But a new package name wouldn't help with that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Stone age programming for space age hardware?
That's interesting, writing a DSL that compiles to C. I've actually inerviewed Gerard Holzamann twice, the first time when he received the ACM Software System Award in 2002 [1] and in 2008 after he moved to JPL [2]. What they use to test distributed software is the Process Meta Language (Promela) which models communication between distributed processes. Now Spin checks all possible models for deadlock, liveness etc. You can also use asserts to test conditions, just as in C. It also uses LTL (linear temporal logic) to formulate statements like, will the railroad crossing always eventually open and such. Two articles about Spin are [3] and [4]. Unfortunately, all four are in Dutch, but, hey, surely somebody here must be able to read that language g. The articles on Spin contain listings in Promela. Now, what Gerard Holzmann told me in the interview, is that NASA is very conservative in it's use of software tools. They don't use C++, just C, and a well defined version of the GNU C compiler at that. The coding standards, which even prohibit the use of C pointers, are aimed to keep everything as simple as possible. Just imagine hundreds of people working over many years to produce code where any error, how trivial it may be, will occur millions of miles away, cost hundreds of millions of dollars, and could damage the reputation of the company and its future funding. Now, if you can use a DSL to make embedded software absolutely failsafe, that would certainly grab NASA's attention. But again, they are very conservative, it seems... [1] http://muitovar.com/pub/pdf/holzmann.pdf [2] http://muitovar.com/pub/pdf/acmaw.pdf [3] http://muitovar.com/pub/pdf/spin1.pdf [4] http://muitovar.com/pub/pdf/spin2.pdf On Tue, 2010-06-08 at 18:27 +0200, Heinrich Apfelmus wrote: Michael Schuerig wrote: I was dumbfounded, although I have known all this. I have no personal experience with either embedded or real time software, but I've been aware that C still is the most popular language for that purpose and that coding standards are very restrictive. The real reason behind my surprise was, that I was wondering how more modern languages could make inroads into such an environment. Haskell without recursion and dynamic memory allocation? Hard to imagine. I have absolutely no experience with real time system, but if I were tasked to write with these coding standards, I would refuse and instead create a small DSL in Haskell that compiles to the requested subset of C. After all, the question is this: why use C if you don't actually use C? The reason is probably that designing/writing a proper DSL is considered too error prone, but with today's theorem provers, this should no longer be the case. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
Sorry for reopening an old thread, but I thought I'd counter some of the negative feedback :) I think this proposal is a great idea! It seems like this would make working with MPTCs much easier. When programming, I generally want to only specify the minimum amount of information to make my code logically unambiguous. If the code contains enough information to infer the proper instantiation without the use of an FD, then I shouldn't need to add a FD. It seems like this would have much more of a it just works feel than the currently alternatives. Also the MPTC + FDs type errors are a pain. I'm not sure if the type errors for your proposal would be better, but it would be hard to make them worse. I do worry about imported instances, (over which we currently have little control) messing up our code. But this would probably be pretty unusual and I feel that this is more of a problem with how instances are imported than with this proposal itself. Anyway, just my two cents, - Job On Thu, May 20, 2010 at 10:34 AM, Carlos Camarao carlos.cama...@gmail.comwrote: This message presents, informally, a proposal to solve Haskell's MPTC (multi-parameter type class) dilemma. If this informal proposal turns out to be acceptable, we (I am a volunteer) can proceed and make a concrete proposal. The proposal has been published in the SBLP'2009 proceedings and is available at www.dcc.ufmg.br/~camarao/CT/solution-to-MPTC-dilemma.pdfhttp://www.dcc.ufmg.br/%7Ecamarao/CT/solution-to-MPTC-dilemma.pdf The well-known dilemma (hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma) is that it is generally accepted that MPTCs are very useful, but their introduction is thought to require the introduction also of FDs (Functional Dependencies) or another mechanism like ATs (Associated Types) and FDs are tricky and ATs, somewhat in a similar situation, have been defined more recently and there is less experience with its use. In www.haskell.org/ghc/dist/current/docs/html/users_guide/type-class-extensions.html there exists a solution to the termination problem related to the introduction of MPTCs in Haskell. In our proposal, neither FDs nor any other mechanism like ATs are needed in order to introduce MPTCs in Haskell; the only change we have to make is in the ambiguity rule. This is explained below. The termination problem is essentially ortogonal and can be dealt with, with minor changes, as described in the solution presented in the above mentioned (type-class-extensions) web page. Let us review the ambiguity rule used in Haskell-98 and after that the ambiguity rule used in GHC. Haskell-98 ambiguity rule (which is adequate for Haskell-98's single parameter type classes) is: a type C = T is ambiguous iff there is a type variable v that occurs in the context (constraint set) C but not in the simple (unconstrained) type T. For example: forall a.(Show a, Read a)=String is ambiguous, because a occurs in the constraints (Show a,Read a) but not in the simple type (String). In the context of MPTCs, this rule alone is not enough. Consider, for example (Example 1): class F a b where f:: a-b class O a where o:: a and k = f o:: (C a b,O a) = b Type forall a b. (C a b,O a) = b can be considered to be not ambiguos, since overloading resolution can be defined so that instantiation of b can determine that a should also be instantiated (as FD b|-a does), thus resolving the overloading. GHC, since at least version 6.8, makes significant progress towards a definition of ambiguity in the context of MPTCs; GHC 6.10.3 User’s Guide says (section 7.8.1.1): GHC imposes the following restrictions on the constraints in a type signature. Consider the type: forall tv1..tvn (c1, ...,cn) = type. ... Each universally quantified type variable tvi must be reachable from type. A type variable a is reachable if it appears in the same constraint as either a type variable free in the type, or another reachable type variable.” For example, type variable a in constraint (O a) in the example above is reachable, because it appears in (C a b) (the same constraint as type variable b, which occurs in the simple type). Our proposal is: consider unreachability not as indication of ambiguity but as a condition to trigger overloading resolution (in a similar way that FDs trigger overloading resolution): when there is at least one unreachable variable and overloading is found not to be resolved, then we have ambiguity. Overloading is resolved iff there is a unique substitution that can be used to specialize the constraint set to one, available in the current context, such that the specialized constraint does not contain unreachable type variables. (A formal definition, with full details, is in the cited SBLP'09 paper.) Consider, in Example 1, that we have a single instance of F and O, say: instance F Bool Bool where f = not instance O Bool where o =
[Haskell-cafe] Re: Stone age programming for space age hardware?
On Tuesday 08 June 2010, Hans van Thiel wrote: Now, what Gerard Holzmann told me in the interview, is that NASA is very conservative in it's use of software tools. They don't use C++, just C, and a well defined version of the GNU C compiler at that. The coding standards, which even prohibit the use of C pointers, are aimed to keep everything as simple as possible. Just imagine hundreds of people working over many years to produce code where any error, how trivial it may be, will occur millions of miles away, cost hundreds of millions of dollars, and could damage the reputation of the company and its future funding. Perhaps it's just my lack of imagination that was driving my original question. I'm just having a hard time imagining how to write reasonably interesting algorithms that way. As I wrote, they might cheat. It's entirely possible to implement dynamic memory on top of fixed-size arrays and use indexes instead of pointers. Of course, I have no idea if that's what they do. Michael -- Michael Schuerig mailto:mich...@schuerig.de http://www.schuerig.de/michael/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] HP/Cygwin and Curl
Thanks Claus, Your condensed summary was my understanding, but if I try to issue Cabal install --reinstall cmu It works every time from a MSYS shell, but with Cygwin I get Linking dist\build\cmu\cmu.exe ... C:\Program Files\Haskell Platform\2010.1.0.0\lib\..\mingw\bin\windres: can't open temporary file `\/cca04932.irc': No such file or directory cabal.exe: Error: some packages failed to install: cmu-1.2 failed during the building phase. The exception was: ExitFailure 1 ('cmu' is just an example; the same behaviour seems apparent whatever the package; I see something very similar when I ask GHC to compile hello.hs.) The general answer I seem to have been getting (and responses I have seen elsewhere top this problem) is 'don't expect the Haskell tools to work with Cygwin'. At any rate it seems that, for some people at least, the latest version of the Haskell tools won't work when launched from Cygwin Bash. Chris -Original Message- From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Claus Reinke Sent: 08 June 2010 09:02 To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] HP/Cygwin and Curl Thanks Stephen--that was related to my original question, about using HP with Cygwin. The answer seems to be No!--you must use MSYS (for real work). The short version: - Cygwin provides commandline tools, compilers and libraries - MSYS provides commandline tools for the MinGW compilers and libraries You can use the commandline tools from either Cygwin or MSYS, but you need to compile and link with the compilers and libraries from MinGW. Cygwin's gcc produces binaries that live in a unix-emulation on top of windows, and depend on a cygwin dll to act as a translator. MinGW's gcc produces native windows binaries. Claus http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/ghci-cygwin.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HP/Cygwin and Curl
Your condensed summary was my understanding, but if I try to issue Cabal install --reinstall cmu It works every time from a MSYS shell, but with Cygwin I get If MSYS works for you, why not stick with it?-) Cygwin with MinGW tools should work, but it is very easy to mess up with this setup (configure scripts might not notice that they are on windows and use the wrong calling convention, Cygwin libraries and compiler tools might be called accidentally if they are installed, and so on). Of course, the more people give up and switch to MSYS, the smaller the chances that such bugs (things that accidentally work when using MSYS, or with a certain directory layout) get reported and fixed. Linking dist\build\cmu\cmu.exe ... C:\Program Files\Haskell Platform\2010.1.0.0\lib\..\mingw\bin\windres: can't open temporary file `\/cca04932.irc': No such file or directory cabal.exe: Error: some packages failed to install: cmu-1.2 failed during the building phase. The exception was: ExitFailure 1 ('cmu' is just an example; the same behaviour seems apparent whatever the package; I see something very similar when I ask GHC to compile hello.hs.) You could try running 'ghc -v hello.hs' and check the windres command for oddities. I have no problems building a simple hello world from Cygwin: $ uname -a CYGWIN_NT-6.1-WOW64 VAIO 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin $ type ghc ghc is hashed (/cygdrive/c/haskell/ghc/ghc-6.12.2.20100522/bin/ghc) $ ghc tst.hs $ ./main.exe Hello, World! The general answer I seem to have been getting (and responses I have seen elsewhere top this problem) is 'don't expect the Haskell tools to work with Cygwin'. That tends to be a self-fulfilling prophesy, similar to 'don't expect the Haskell tools to work on Windows (because so many people rely on unixisms)'. But the result is that problems do surface more often in this configuration. If you want to investigate, you could file a report on the HP trac. Claus At any rate it seems that, for some people at least, the latest version of the Haskell tools won't work when launched from Cygwin Bash. Chris -Original Message- From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Claus Reinke Sent: 08 June 2010 09:02 To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] HP/Cygwin and Curl Thanks Stephen--that was related to my original question, about using HP with Cygwin. The answer seems to be No!--you must use MSYS (for real work). The short version: - Cygwin provides commandline tools, compilers and libraries - MSYS provides commandline tools for the MinGW compilers and libraries You can use the commandline tools from either Cygwin or MSYS, but you need to compile and link with the compilers and libraries from MinGW. Cygwin's gcc produces binaries that live in a unix-emulation on top of windows, and depend on a cygwin dll to act as a translator. MinGW's gcc produces native windows binaries. Claus http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/ghci-cygwin.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HP/Cygwin and Curl
with Cygwin I get Linking dist\build\cmu\cmu.exe ... C:\Program Files\Haskell Platform\2010.1.0.0\lib\..\mingw\bin \windres: can't open temporary file `\/cca04932.irc': No such file or directory This sounds very much like a temporary-filename issue. The reported filename's lack of a valid directory specifier looks highly suspicious to me. Are your TEMP, TEMPDIR, TMP, and TMPDIR environment variables set? Are their values sensible? Do you have appropriate permissions on the directories they point to? These are the kinds of thing I usually need to check when setting up a new Cygwin build environment. Admittedly, we do not use cabal on Windows (firewall prevents it from working), but the other ghc tools generally seem to work without problems for us under Cygwin. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Problems with threading?
Louis Wasserman wasserman.louis at gmail.com writes: While working on the Shootout, I noticed the following benchmarks: http://shootout.alioth.debian.org/u64/program.php?test=chameneosreduxlang=ghcid=3 http://shootout.alioth.debian.org/u64q/program.php?test=chameneosreduxlang=ghcid=3 [...] I'd like to see it improved. [...] One difficulty is that the single meeting place is a bottleneck. The only parallel activity I can see for the chameneos creatures is standing around in queues. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Please check your dependencies on fgl
Ian Lynagh ig...@earth.li writes: On Mon, Jun 07, 2010 at 11:50:44AM -0700, Donald Bruce Stewart wrote: A complete rewrite with a new maintainer: fgl-awesome In 10 years time, we don't want to have fgl fgl-awesome fgl-great fgl-joe which all do the same thing, and have an unclear relationship to each other. Definitely (though hopefully we wouldn't pick names like fgl-awesome anyway...). I think the important question is: Once the new FGL is finished, will there be a good reason (other than backwards compatibility) for people to use the current FGL? If yes, then different names should be used. Otherwise, no matter how different the API is, keeping the same name is the right thing to do. And this is why we're going to request the community's input on our API design: to try and avoid the situation where there's a specific reason to keep using the old one. As it stands, the only real advantage that I can think of is that the new version uses extensions, the old version doesn't (and hence is more compatible). So if there is consensus that the new design is a better fgl, I think it ought to keep the name. Which is what we're trying to build (the consensus, that is). Don has started a wiki page with the arguments here, and I've already added my 2c: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
Gene A yumag...@gmail.com writes: Oh lord yes... just call it fgl3 and leave the fgl package alone. This is a source based community here... so you take a package that has a dependency on another library and you go out and get that to cover the dependency and the API is not the same!!! AND especially if that might be the only thing you will ever use that lib for ... and you have to stop and rewrite the original.. and as someone else said with maybe documentation of that API that is not maybe finished or... NO ... At that point the person will probably just DISCARD the compile on the lib or program that had the dependency.. rather then put the effort in to learn an entire API that doesn't match up.. BAD IDEA!! So as soon as you write the basics of an API you can never change it, just extend it to avoid making people have to re-write their code that uses it? That road leads down the path of complacency and stagnation IMHO... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Execution call graph pruning
C K Kashyap ckkash...@gmail.com writes: Hi, I have a call grah which contains information of the edges in the following format caller callee count (time spent by the caller) === foo bar 10100 xxx yyy 2010 zzz yyy 1010 (I used pintool pintool.org to generate this call graph) Now, the problem is that the graph is huge and it take a long to render using 'dot' or use any visualizing tool. Even if they render, it's too cluttered to be useful. I wanted to prune the graph in such a way that I'd have only the edges corresponding to the top 10% of the time consumers. What would be a good way to do such a thing? Has anyone written some utility that I could use? Well, graphviz [1] lets you parse Dot code, so you could then do a filter on it (I'm currently working on ways of letting you interact with the Dot code better). [1]: http://hackage.haskell.org/package/graphviz Also, to let you skip a step prof2dot [2] will create the Dot code for you. [2]: http://hackage.haskell.org/package/prof2dot -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: package naming policy
Don Stewart d...@galois.com writes: Yes, my intent here is to produce a set of guidelines for maintainers of important packages, that ensures we balance stability with innovation. We have a great document for what to consider when adding packages to the HP, for example: http://trac.haskell.org/haskell-platform/wiki/AddingPackages But nothing yet for maintainers who want to keep a package moving along. As part of this, we should consider if we want an official process to do what I've done to kick-off this whole discussion: have a way of telling users Oj! New version coming up with heaps of changes!. Whilst major projects might have their own mailing lists, not all users might be subscribed to them, etc. Should we stick with what I've done and just email haskell@ and haskell-c...@? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
Sorry, I hit Reply instead of Reply To All. -- Forwarded message -- From: Jake McArthur jake.mcart...@gmail.com Date: Tue, Jun 8, 2010 at 6:16 PM Subject: Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons To: Don Stewart d...@galois.com Making a new name for an existing package subverts the intended meaning of major revision numbers. Libraries that break as a result of a major revision should have had more specific dependencies, and tutorials that go out of date should also have specified the version number of the package for which they were intended. It's a package maintainer's responsibility to respect version number conventions. I don't believe it is a package maintainer's responsibility to account for blatant misuse of it. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: package naming policy
On Tue, Jun 8, 2010 at 4:13 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Don Stewart d...@galois.com writes: Yes, my intent here is to produce a set of guidelines for maintainers of important packages, that ensures we balance stability with innovation. We have a great document for what to consider when adding packages to the HP, for example: http://trac.haskell.org/haskell-platform/wiki/AddingPackages But nothing yet for maintainers who want to keep a package moving along. As part of this, we should consider if we want an official process to do what I've done to kick-off this whole discussion: have a way of telling users Oj! New version coming up with heaps of changes!. Whilst major projects might have their own mailing lists, not all users might be subscribed to them, etc. Should we stick with what I've done and just email haskell@ and haskell-c...@? Yes, and posting to reddit and having an article on planet haskell about it helps too. There are lots of ways to get the same information and using more of them will help you reach your audience. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: package naming policy
Jason Dagit da...@codersbase.com writes: On Tue, Jun 8, 2010 at 4:13 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: As part of this, we should consider if we want an official process to do what I've done to kick-off this whole discussion: have a way of telling users Oj! New version coming up with heaps of changes!. Whilst major projects might have their own mailing lists, not all users might be subscribed to them, etc. Should we stick with what I've done and just email haskell@ and haskell-c...@? Yes, and posting to reddit and having an article on planet haskell about it helps too. There are lots of ways to get the same information and using more of them will help you reach your audience. Well, someone else would have to do the posting on reddit for me; I waste too much time as-is reading it let alone posting there and getting involved in the discussions on yet another front! ;-) I'll do up a blog post in the next day or so to get it on planet though. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons
I don't really see this listed on your list, but maybe I missed it. Happstack has been affected by QuickCheck 1 - QuickCheck 2, parsec 2 - 3, and HaXml 1.13 - 1.20. Those packages are common, and people often want to use happstack with other libraries that also use those packages. The problem is that if we upgrade to the newer versions, then people can't use happstack with libraries that use the old version. For example, when we upgrade to QuickCheck 2, gitit no longer installed, because some dependency of gitit still used (and perhap still does) QuickCheck 1. We are now faced with the same problem with HaXml. Do we upgrade to 1.20 and stick with 1.13 for a while? Either way we cause incompatibilities. The the cause of QuickCheck, 99% of the time, it would have been ok to link the app against QC1 and QC2, because no one ever tried to combine the QC1 tests and the QC2 tests. So, in that cause, making QC1 and QC2 completely different packages would have solved our problem. Duncan C, also proposed a system whereby we could declare QuickCheck as an 'internal' dependency -- meaning we never export any QC2 functions or types to the outside word, so it is safe to link against other versions of QC. That would have worked fine as well, but the proposal does not seem to have gotten any traction yet. That is unfortunate, because it seems useful. In the case of HaXml, things are a bit trickier. It is more likely that people are going to want to use the HaXml stuff we export with other libraries that use HaXml, so everyone would have to be using the same version of HaXml then. At the same time, not very many people actually use the HaXml stuff in happstack, even if they are using another library that use HaXml. So, for most people the version mismatch isn't really an issue. So, like QC, it would actually probably be better for use if HaXml 1.13 and 1.20 had unique package names, so we could link against multiple HaXml versions. Of course, in the case of QC2 and HaXml, the ultimate solution is that everyone upgrades to the latest, and then the problem goes away. But, once you start depending on a larger number of packages directly and indirectly, it does not take very long before you run into someone that has not updated to the latest, and then you are kind of stuck... As a maintainer, I have no idea when the right time to switch to HaXml 1.20 is.. and that is an issue. That same would be true of fgl (though, fortunately, happstack doesn't use that yet). The only solution I have at the moment, is to upgrade to HaXml 1.20, and then send patches to any other direct or indirect dependencies of happstack that use HaXml and get them upgraded as well.. Maybe that is the best solution.. though it is also a lot of work. - jeremy On Tue, Jun 8, 2010 at 10:08 AM, Don Stewart d...@galois.com wrote: There have been a few cases of major API / rewrites to famous old packages causing problems, including: * QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL a similar opportunity is present with 'fgl', where the new maintainers are seeking to improve the code. Below I try to summarise the pros and cons of calling the new rewrite/api 'fgl', in the hope we can identify a path that minimizes disruption to users. A group of developers is planning to write a new graph library for Haskell. * They maintain an existing package called 'fgl'. * 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/ * The new library will have different authors and a different API. * They would like the new library 'fgl'. It is a controversial step to write a new library and give it the same name as an existing, famous library. Let's look at the arguments. = Reasons to use the new name = * The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption. * Rewrites are effective if the name is preserved. E.g. QuickCheck 2. * It is the maintainer's right to modify APIs as they see fit. * Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade. * Relatively few packages use fgl. So damage is limited. = Reasons not to use the name = * Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct * Doesn't matter if the old fgl is still around. If the new code is better, it will be adopted on its own merits (see e.g. bytestrings vs packedstring, vector vs uvector) Let the market decide if it is better, rather than forcing us. * The package has been stable for ~10 years -- why change a stable API? It is already perfect * The new package really isn't the same package in any sense. * Rewrites by new teams damage the brand of famous packages (e.g. parsec 3) * No
Re: [Haskell-cafe] cabal problem on OS X
I am also experiencing this problem. I read that the problem was fixed in the latest Cabal-install version. But I'm not sure, as I tried to install the latest Cabal-install and got 50 linker errors which I'm not prepared to tackle until the weekend. On 8 June 2010 18:21, Gordon J. Uszkay uszka...@mcmaster.ca wrote: Did you manage to fix this problem, or are there any updates on it? I am now having the same issue - presumably due to updating my Mac OS X version, because cabal was working fine before that. I can't upgrade cabal or install anything either, same reason. Gordon J. Uszkay uszka...@mcmaster.ca On May 22, 2010, at 7:27 AM, Ivan Lazar Miljenovic wrote: Bill Atkins watk...@alum.rpi.edu writes: When I run cabal update on my Mac (Snow Leopard, Intel), I get: % cabal update Downloading the latest package list from hackage.haskell.org cabal: Codec.Compression.Zlib: incompatible zlib version I'm going to randomly guess that the version of the C zlib library that Cabal was indirectly built against is different to the one on your machine. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] strange errors with unix-compat
Hello, when compiling unix-compat I get this: 4 of 4] Compiling System.PosixCompat.Extensions ( dist/build/System/PosixCompat/Extensions.hs, dist/build/System/PosixCompat/Extensions.o ) cbits/HsUnixCompat.c: In function `unix_major': cbits/HsUnixCompat.c:4:0: warning: implicit declaration of function `major' cbits/HsUnixCompat.c: In function `unix_minor': cbits/HsUnixCompat.c:8:0: warning: implicit declaration of function `minor' cbits/HsUnixCompat.c: In function `unix_makedev': cbits/HsUnixCompat.c:12:0: warning: implicit declaration of function `makedev' /usr/gnu/bin/ar: creatin and an ghci -package gives me this: GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package unix-2.3.2.0 ... linking ... done. ghc: /home/guenni/.cabal/lib/unix-compat-0.1.2.1/ghc-6.10.4/HSunix-compat-0.1.2.1.o: unknown symbol `major' Loading package unix-compat-0.1.2.1 ... linking ... ghc: unable to load package `unix-compat-0.1.2.1' How can I fix this? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons
Jeremy Shaw jer...@n-heptane.com writes: I don't really see this listed on your list, but maybe I missed it. Happstack has been affected by QuickCheck 1 - QuickCheck 2, parsec 2 - 3, and HaXml 1.13 - 1.20. Those packages are common, and people often want to use happstack with other libraries that also use those packages. The problem is that if we upgrade to the newer versions, then people can't use happstack with libraries that use the old version. For example, when we upgrade to QuickCheck 2, gitit no longer installed, because some dependency of gitit still used (and perhap still does) QuickCheck 1. My understanding is that this is caused by a limitation in ghc-pkg which can't tell the difference between re-exposed and only-used-internally dependencies. I recall having a discussion with either you or someone else from the happstack team about why it isn't applicable there, but the QuickCheck problem can be solved in the general case by having its dependency be a compile-time-only option which is disabled by default. However, this is definitely a major problem with parsec, HaXml, etc. and probably what I consider the main argument _against_ keeping the same name for fgl, though this can occur with packages even with a relatively minor API change (e.g. haskell-src-exts going from 1.6 to 1.7; the API change was minor but until all package maintainers upgraded their packages to work with 1.7 there would be some inconsistencies). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons
On Tue, Jun 8, 2010 at 7:06 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: I recall having a discussion with either you or someone else from the happstack team about why it isn't applicable there, but the QuickCheck problem can be solved in the general case by having its dependency be a compile-time-only option which is disabled by default. Not really. Cabal likes to recompile things, and it won't remember that I compiled another library with quickcheck enabled. So if library B depends on library A with quickcheck enabled, it may still happen that after I install library A with quickcheck enabled, cabal will decide to recompile A again when building library B, and it will build A without quickcheck, causing B to fail... However, this is definitely a major problem with parsec, HaXml, etc. and probably what I consider the main argument _against_ keeping the same name for fgl, though this can occur with packages even with a relatively minor API change (e.g. haskell-src-exts going from 1.6 to 1.7; the API change was minor but until all package maintainers upgraded their packages to work with 1.7 there would be some inconsistencies). Right. Minor dependencies have the same issue. The only difference is that it is generally less work for maintainers to update their code. So maybe it happens faster/more often. But, we still run into that issue with happstack as well. We have fixed it by sending patches upstream. Since they are small patches it is usually easy to get them created and applied than something like HaXml 1.13 - 1.19. - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons
Jeremy Shaw jer...@n-heptane.com writes: On Tue, Jun 8, 2010 at 7:06 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: I recall having a discussion with either you or someone else from the happstack team about why it isn't applicable there, but the QuickCheck problem can be solved in the general case by having its dependency be a compile-time-only option which is disabled by default. Not really. Cabal likes to recompile things, and it won't remember that I compiled another library with quickcheck enabled. So if library B depends on library A with quickcheck enabled, it may still happen that after I install library A with quickcheck enabled, cabal will decide to recompile A again when building library B, and it will build A without quickcheck, causing B to fail... You of course mean cabal-install, not Cabal when talking about recompiling things (I know, I'm being picky, but still...). Also, that problem is the reason why I recognise that for happstack can't at the moment have the QuickCheck dependency optional. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and consf
From: Stephen Tetley stephen.tet...@gmail.com Hello all While new libraries develop at pace, their documentation rarely does; so I'd have to disagree with John's claim that re-naming libraries makes development by new users harder. I'd argue that having tutorials not work for later revisions is more confusing than having various packages doing the same thing. I'd also contend that beginners are better off lagging behind the cutting edge and using Parsec 2, QuickCheck 1, Haskore-vintage, as the earlier version all have comprehensive documentation - Parsec 2 and Haskore have extensive manual/tutorials, QuickCheck 1 was small enough that the original QuickCheck paper covered its use. Lagging behind the cutting edge is one thing, but learning possibly-deprecated or soon-to-be-obsolete interfaces is another. I would contend that in each case the intention is for the earlier version to be superseded because of significant (hopefully user-driven) benefits provided by the new design. Now beginners are in the very frustrating situation of having invested time with a codebase that they learn is obsolete. Depending on the significance of the changes, some amount of that knowledge can be carried forward, but it's a disheartening position to be in and I would expect a few could give up entirely at that point. I think that's worse than floundering around with no documentation at all. Of course a better solution is for maintainers to update their manuals! An advantage of separate names (both for the package name and module name-space) is that its easier to have both packages installed at the same time - the old one to work with while learning the package, the new one if other installed packages depend on it. This can still be done with package-hiding but its less straight-forward. With proper .cabal files and dependency bounds this isn't an issue. If you're working in ghci I think it's the same amount of work either way, at least with my workflow. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and consf
On Tue, Jun 8, 2010 at 6:28 PM, John Lato jwl...@gmail.com wrote: From: Stephen Tetley stephen.tet...@gmail.com Hello all While new libraries develop at pace, their documentation rarely does; so I'd have to disagree with John's claim that re-naming libraries makes development by new users harder. I'd argue that having tutorials not work for later revisions is more confusing than having various packages doing the same thing. I'd also contend that beginners are better off lagging behind the cutting edge and using Parsec 2, QuickCheck 1, Haskore-vintage, as the earlier version all have comprehensive documentation - Parsec 2 and Haskore have extensive manual/tutorials, QuickCheck 1 was small enough that the original QuickCheck paper covered its use. Lagging behind the cutting edge is one thing, but learning possibly-deprecated or soon-to-be-obsolete interfaces is another. I would contend that in each case the intention is for the earlier version to be superseded because of significant (hopefully user-driven) benefits provided by the new design. Now beginners are in the very frustrating situation of having invested time with a codebase that they learn is obsolete. Depending on the significance of the changes, some amount of that knowledge can be carried forward, but it's a disheartening position to be in and I would expect a few could give up entirely at that point. I think that's worse than floundering around with no documentation at all. Of course a better solution is for maintainers to update their manuals! Or write translator tools for upgrading to the new API :) Pipe dream? Maybe. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Tricks with GMap -- question about conflicts w/ indexed type families
Ryan Newton wrote: What I would next *like* to do is something like the following: import qualified Data.IntMap as DI instance FitInWord t = GMapKey t where data GMap t v = GMapInt (DI.IntMap v) deriving Show The problem is that there's already a more general instance of GMapKey that handles pairs by representing them as nested GMaps: instance (GMapKey a, GMapKey b) = GMapKey (a, b) where data GMap (a, b) v= GMapPair (GMap a (GMap b v)) Ideally, I want both of these to coexist (and to prioritize the more specific one). With normal type classes, OverlappingInstances can handle this, but with type families I get an error like the following: First of all, if we forget about data families, OverlappingInstances still won't give us the desired behavior. GHC chooses overlapping instances based only on the instance head type, disregarding all constraints. Therefore, when asked to choose an instance for GMapKey (Int16,Int16), GHC would choose the second instance as it is more specific: the type (a,b) is more specific that the type t. Again, the constraints such as FitInWord are not used when choosing instances. This issue is discussed in detail at Choosing a type-class instance based on the context http://okmij.org/ftp/Haskell/types.html#class-based-overloading and on the Wiki Page http://haskell.org/haskellwiki/GHC/AdvancedOverlap These pages explain how can we make class constraints bear on the instance selection. But we still have the second problem: data families do not permit overlapping declarations. At first blush, it appears impossible to define GMapKey for specific pairs and default to the generic GMap instance for general pairs. Fortunately, a solution exists, shown below. The idea is to define an auxiliary type class (without data families). Such a type class permits overlapping instances and so makes possible the desired behavior of specific instances with the generic default. {-# LANGUAGE FlexibleInstances, FlexibleContexts #-} {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE OverlappingInstances #-} module GM where import Data.Int import Data.Word import Data.Bits import qualified Data.IntMap as IM -- = Begin a simplified GMap package -- A simplified class GMapKey class GMapKey t where data GMap t :: * - * empty :: GMap t v lookup :: t - GMap t v - Maybe v instance GMapKey Int16 where data GMap Int16 v = GMI16 (IM.IntMap v) empty = GMI16 $ IM.empty lookup k (GMI16 m) = IM.lookup (fromIntegral k) m instance GMapKey Int32 where data GMap Int32 v = GMI32 (IM.IntMap v) empty = GMI32 $ IM.empty lookup k (GMI32 m) = IM.lookup (fromIntegral k) m -- Generic instance for pairs instance (GMapKey a, GMapKey b) = GMapKey (a, b) where data GMap (a, b) v= GMapPair (GMap a (GMap b v)) empty = GMapPair $ empty lookup k (GMapPair m) = error Invoking the generic instance for pairs -- = End the simplified GMap package -- The following is an optimization, which should appear in a different -- module. The optimization should not disturb the original GMap code. -- The following optimization is Ryan Newton's code -- A class for values that fit within one word class FitInWord v where toWord :: v - Word fromWord :: Word - v instance FitInWord (Int16,Int16) where toWord (a,b) = shiftL (fromIntegral a) 16 + (fromIntegral b) fromWord n = (fromIntegral$ shiftR n 16, fromIntegral$ n .. 0x) -- Now we wish to define optimized instances of GMapKey for -- pairs of items that fit within a word. -- The following answers Ryan Newton's question -- Define our own product type, to avoid overlapping instances with the -- general GMapKey for pairs -- It's a newtype: it has no run-time overhead newtype OptimalPair a b = OptimalPair (a,b) instance FitInWord (a,b) = GMapKey (OptimalPair a b) where data GMap (OptimalPair a b) v = GMapInt (IM.IntMap v) deriving Show empty = GMapInt IM.empty lookup (OptimalPair k) (GMapInt m) = IM.lookup (fromIntegral$ toWord k) m -- Auxiliary class to choose the appropriate pair class ChoosePairRepr a b pr | a b - pr where choose_pair :: (a,b) - pr choosen_pair :: pr - (a,b) instance ChoosePairRepr Int16 Int16 (OptimalPair Int16 Int16) where choose_pair = OptimalPair choosen_pair (OptimalPair p) = p -- Repeat the above for all other optimal pairs: -- (Int8, Int16), (Int16, Int8), etc. -- Template Haskell is very good to generate all such boiler-plate instances -- Choose a generic pair for all other pairs of values instance pr ~ (a,b) = ChoosePairRepr a b pr where choose_pair = id choosen_pair = id -- tests -- A specific instance is chosen test1 = let m = empty in GM.lookup (choose_pair (1::Int16,2::Int16)) m -- Nothing -- A general pair instance is chosen test2 = let m =
Re: [Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and consf
On 9 June 2010 12:11, Jason Dagit da...@codersbase.com wrote: Or write translator tools for upgrading to the new API :) Pipe dream? Maybe. Too an extent, yes: the types are more generalised so it's going to be difficult to do automatic translations. However, Thomas has demonstrated that you can write any instance of the new class as an instance of the old classes and vice versa just using class methods... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
On Jun 8, 2010, at 15:32 , Job Vranish wrote: It seems like this would make working with MPTCs much easier. When programming, I generally want to only specify the minimum amount of information to make my code logically unambiguous. If the code contains enough information to infer the proper instantiation without the use of an FD, then I shouldn't need to add a FD. It seems like this would have much more of a it just works feel than the currently alternatives. I can't help but think that the it just works mentality leads to duck typing. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Stone age programming for space age hardware?
On Jun 8, 2010, at 14:22 , Michael Schuerig wrote: On Tuesday 08 June 2010, Heinrich Apfelmus wrote: I have absolutely no experience with real time system, but if I were tasked to write with these coding standards, I would refuse and instead create a small DSL in Haskell that compiles to the requested subset of C. Now, the interesting question is, whether it is possible to define a DSL that's expressive enough and still can be translated to a very restrictive subset of C. I wouldn't expect the on-board functionality of a space probe or rover to be trivial. Hm. Atom? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal problem on OS X
Hi, For me it turned out to be some problem with MacPorts, removing MacPorts (with all its installed ports) solved the problem regarding ZLib. I assume that a less drastic measure would also work (only remove selected ports or remove the ports from your path). Regards, Jeroen 2010/6/9 Christopher Done chrisd...@googlemail.com: I am also experiencing this problem. I read that the problem was fixed in the latest Cabal-install version. But I'm not sure, as I tried to install the latest Cabal-install and got 50 linker errors which I'm not prepared to tackle until the weekend. On 8 June 2010 18:21, Gordon J. Uszkay uszka...@mcmaster.ca wrote: Did you manage to fix this problem, or are there any updates on it? I am now having the same issue - presumably due to updating my Mac OS X version, because cabal was working fine before that. I can't upgrade cabal or install anything either, same reason. Gordon J. Uszkay uszka...@mcmaster.ca On May 22, 2010, at 7:27 AM, Ivan Lazar Miljenovic wrote: Bill Atkins watk...@alum.rpi.edu writes: When I run cabal update on my Mac (Snow Leopard, Intel), I get: % cabal update Downloading the latest package list from hackage.haskell.org cabal: Codec.Compression.Zlib: incompatible zlib version I'm going to randomly guess that the version of the C zlib library that Cabal was indirectly built against is different to the one on your machine. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe