October 2008 - Libraries

Repair to floating point enumerations?
by Malcolm Wallace 22 Oct '08

22 Oct '08

Dear Haskell-Primers (and libraries). Recently, Phil Wadler has pointed out a weird anomaly in the Haskell'98 Prelude, regarding numeric enumerations for Floats/Doubles: Prelude> [0, 0.3 .. 1.1] [0.0,0.3,0.6,0.899999,1.2] What is odd is that the last value of the list is much larger than the specified termination value. But this is exactly as specified by the Haskell'98 Report. http://haskell.org/onlinereport/basic.html#sect6.3.4 "For Float and Double, the semantics of the enumFrom family is given by the rules for Int above, except that the list terminates when the elements become greater than e3+i/2 for positive increment i, or when they become less than e3+i/2 for negative i. We have discussed this question (and related ones, such as whether Float and Double belong in the Enum class at all) several times before, and I do not wish to rehash all of those points again e.g.: http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg07289.html http://www.haskell.org/pipermail/haskell/2001-October/008218.html http://www.haskell.org/pipermail/haskell/2002-October/010607.html Phil proposes that, although retaining the instances of Enum for Float and Double, we simplify the definitions of the numericEnumFrom family: numericEnumFromThenTo :: (Fractional a, Ord a) => a -> a -> a -> [a] numericEnumFrom = iterate (+1) numericEnumFromThen n m = iterate (+(m-n)) n numericEnumFromTo n m = takeWhile (<= m) (numericEnumFrom n) numericEnumFromThenTo n m p = takeWhile (<= p) (numericEnumFromThen n m) The particular feature of note is that the odd fudge factor of (1/2 * the increment) is removed. The inexact nature of floating point numbers would therefore cause a specification like [ 0.0, 0.1 .. 0.3 ] to yield the sequence [ 0.0, 0.1, 0.2 ] that is, to omit the upper bound, because (3 * 0.1) is actually represented as 0.30000000000004, strictly greater than 0.3. Phil argues that this behaviour is more desirable: "the simple fix is that the user must add a suitable epsilon to the upper bound. The key word here is *suitable*. The old definitions included completely bizarre and often highly unsuitable choices of epsilon." This proposal seems to me to improve the consistency of the enumeration syntax across both the integral and floating types. Some users may still be surprised, but the surprise will be easier to explain. I am bringing this question to the attention of all who are interested in Haskell Prime, because it seems like a sensible and well-reasoned change. Discussion on whether to adopt this proposal for H' is welcome. But as maintainer and bug-fixer of the Haskell'98 Report, I have also been asked whether we should make this change retrospectively to the Haskell'98 language (as a "typo"). Since it involves not merely an ordinary library function, but a Prelude function, and moreover a function that is used in the desugaring of syntax, it is less clear to me whether to alter Haskell'98. Thoughts? Regards, Malcolm

10 11

Arch Haskell News: Oct 18 2008
by Don Stewart 18 Oct '08

18 Oct '08

= News about Haskell on Arch Linux = Arch Linux now has 639 Haskell packages in AUR. That’s an increase of 15 new Haskell packages in the last 7 days. Growth appears to be holding steady at just over 2 new packages a day on Hackage this month. Noteworthy * haskell-gnuplot-0.2: “2D and 3D plots using gnuplot” * alex-2.3: “Alex is a tool for generating lexical analysers in Haskell” * happy-1.18.1: “Happy is a parser generator for Haskell” * haskell-tfp-0.1: “Type-level programming library using type families” Full details on the site. http://archhaskell.wordpress.com/2008/10/18/arch-haskell-news-oct-18-2008/

1 0

Re: [Haskell-cafe] ANNOUNCE: Glob 0.1, globbing library
by Krzysztof Skrzętnicki 18 Oct '08

18 Oct '08

On Fri, Oct 17, 2008 at 22:02, Matti Niemenmaa <matti.niemenmaa+news(a)iki.fi> wrote: > Greetings to all, > > I hereby announce the release of Glob 0.1, a small library for glob-matching > purposes based on a subset of zsh's syntax. > > Web page at: http://iki.fi/matti.niemenmaa/glob/index.html > Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Glob > > Simple example: match (compile "foo*baz") "foobarbaz" == True. > > It can also group the contents of a directory given a list of patterns to match: > globDir [compile "foo*baz"] "<a directory containing foobarbaz and joe>" gives > (["dir/foobarbaz"],["dir/joe"]). > > Comments, complaints, feature requests, bug reports are all welcome. It should > work on both GHC 6.8 and 6.10, but I've only tested the latter. > Hello I tried out your package, but it doesn't seem to work correctly on Windows. I checked the code and it has directory separator hard coded, which seem to be the source of problems. Please see: http://www.haskell.org/ghc/docs/latest/html/libraries/filepath/System-FileP… All best Christopher Skrzętnicki

2 2

Re: Compiling regex-posix-0.93.2 on windows
by Chris Kuklewicz 17 Oct '08

17 Oct '08

I am not sure what is going wrong. I have not been using Haskell on windows. I am also copying this reply to haskell-cafe and libaries mailing lists. Does anyone know? Parnell Flynn wrote: > I am having a terrible time compiling the 0.93.2 version of the > regex-posix library on windows XP. > > I have Cygwin and MinGW installed and I have a version of the regex.h > header in C:/cygwin/usr/include what shared libraries do I need? > > Here is a copy of the error it finds the include but is unable to link. > > This links to the standard c library version of regular expressions. > > The corresponding c header file is regex.h and there is a chance you > > will need to edit the end of the regex-posix.cabal file to find the > > include directory and/or library. > > Preprocessing library regex-posix-0.93.2... > > dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0x85):Wrap_hsc_make.c: > undefined reference to `_impure_ptr' > > dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0xc9):Wrap_hsc_make.c: > undefined reference to `_impure_ptr' > > dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0xf1):Wrap_hsc_make.c: > undefined reference to `_impure_ptr' > > dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0x125):Wrap_hsc_make.c: > undefined reference to `_impure_ptr' > > dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0x159):Wrap_hsc_make.c: > undefined reference to `_impure_ptr' > > dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0x18d):Wrap_hsc_make.c: > more undefined references to `_impure_ptr' follow > > collect2: ld returned 1 exit status > > linking dist\build\Text\Regex\Posix\Wrap_hsc_make.o failed > > command was: y:\ghc\ghc-6.8.2\bin\ghc.exe -optl-LC:/cygwin/lib > dist\build\Text\Regex\Posix\Wrap_hsc_make.o -o > dist\build\Text\Regex\Posix\Wrap_hsc_make.exe > > bash-3.2$ > > Thanks, > > Parnell > > Parnell Flynn • 230 South Lasalle Street • Suite 400 • Chicago, IL 60604 > • 312.244.5317 (o) • parnell___.flynn(a)ronin-capital.com_ > <mailto:parnell.flynn@ronin-capital.com> >

1 0

OpenGL+GLUTwith ghc-6.10 ?
by Conal Elliott 17 Oct '08

17 Oct '08

Has anyone gotten OpenGL+GLUT to work with ghc-6.10? It crashes for me on createWindow (from Graphics.UI.GLUT.Window). I'm using the ghc-6.10.0.20081007 from a win32 installer, along with OpenGL-2.2.1.1 and GLUT-2.1.1.2 from Hackage. Thanks, - Conal

1 0

2008-10-11 Hackage status with GHC 6.10
by Don Stewart 17 Oct '08

17 Oct '08

Daily update of the state of Hackage wrt. GHC 6.10 release candidates. Lots of packages were updated today, Cabal 1.6 and cabal-install 0.6 were also put out. Things are in a good shape. Note that you'll need a "soft dep" in your cabal index file, base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2 for best results. Using GHC 6.10 RC, Cabal 1.6 and cabal-install 1.16, of 684 libraries and apps tried in total, 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 74 DependencyFailed 134 BuildFailed 455 InstallOk Compared to GHC 6.8.x's results, there are now *48* packages that produce different results, or *6%* (down 2% from yesterday). The most common issues are, * Changes to Arrow class definition * Changes to types of Map and Set functions * Cabal changes * Changes to ghc-api * Changes to when 'forall' is parsed (add Rank2Types) * GHC.Prim was moved, * Changes to -fvia-C and headers * GADT changes, * pragma warnings tightened * Integer constructors have moved * New warnings and used -Werror How to address these, as library maintainers, is addressed here, http://haskell.org/haskellwiki/Upgrading_packages Packages that have broken wrt. the new core library APIs are, ArrayRef-0.1.2 CLASE-2008.9.23.2 EdisonCore-1.2.1.2 HPDF-1.4 HaLeX-1.1 Hashell-0.15 Hipmunk-0.2 MemoTrie-0.0 NewBinary-0.1.1 PArrows-0.1 TypeCompose-0.5 WebBits-0.9.2 YamlReference-0.9.2 Yampa-0.9.2.2 arrows-0.4 bytestring-show-0.2 cabal-setup-1.2.1 chp-1.1.0 cmath-0.3 fixpoint-0.1 hasim-0.1 hask-home-2007.12.6 heap-0.4.0 hetris-0.2 hexpat-0.2 hinstaller-2008.2.16 hint-0.2.4.1 hslackbuilder-0.0.1 hxt-8.1.0 iException-0.0.1 libGenI-0.16.1 list-extras-0.2.2 logfloat-0.9.1 mage-1.1.0 numeric-prelude-0.0.4 plugins-1.3 quantum-arrow-0.0.4 regex-tdfa-0.94 streamproc-1.1 stringtable-atom-0.0.4 typalyze-0.1.1 unicode-prelude-0.1 xmonad-utils-0.1 yhccore-0.9 GHC bugs are suspected for, xmonad-contrib, stream-fusion, harpy, OpenAFP Tickets are open for these. Build reports for these packages were posted yesterday, http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/15430 -- Don

5 15

Proposal #2659: Add sortOn and friends to Data.List
by Twan van Laarhoven 15 Oct '08

15 Oct '08

Hello list, Almost all uses of sortBy in user code use 'comparing', 'on' or a similar construction [1]. I think we should add a function that makes this common behavior more convenient: sortOn :: Ord b => (a -> b) -> [a] -> [a] For consistency we should also add *On for the other *By functions in Data.List: nubOn :: Eq b => (a -> b) -> [a] -> [a] deleteOn :: Eq b => (a -> b) -> a -> [a] -> [a] deleteFirstsOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] unionOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] intersectOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] groupOn :: Eq b => (a -> b) -> [a] -> [[a]] sortOn :: Ord b => (a -> b) -> [a] -> [a] insertOn :: Ord b => (a -> b) -> a -> [a] -> [a] maximumOn :: Ord b => (a -> b) -> [a] -> a minimumOn :: Ord b => (a -> b) -> [a] -> a (nubSortOn :: Ord b => (a -> b) -> [a] -> [a]) -- see #2629 -- Naming -- "On": The reason for the "on" suffix is that it relates to the "on" function from Data.Function: "sortOn f = sort (compare `on` f)". In code, "sortOn fst" is reasonably natural, "sortBy fst" would be better but that is already taken. "With": Another possible choice is the "with" suffix. There is some precedence for this choice [2]. A big disadvantage is that the "with" suffix is commonly used for combining functions, as in Data.Map.unionWith. Making a Data.List.unionWith that does something completely different sounds like a bad idea. "ByComparing": Defining sortByComparing f = sortBy (comparing f) makes sense, naming wise. A disadvantage of this name is that it is too long. Also, we would get a distinction between "groupByEquating" and "sortByComparing". -- Variations -- When f is a slow function the call "sortOn f xs" recomputes f more than necessary. A version that caches the result of f is easy to define: sortOn' f = map fst . sortOn snd . map (\x -> (x,f x)) This is perhaps not the best name, since ' usually means strictness. -- Descending sort-- To be able to sort lists in reverse order, a simple newtype should be added to Data.Ord: newtype Down a = Down { getDown :: a } instance Ord a => Ord (Down a) where Down x < Down y = y < x Now "sortOn Down xs == reverse (sort xs)". The name Down comes from [2], maybe Desc is a better name? -- Proposal-- Ticket: #2659 (for sortOn and friends) Ticket: #2660 (for Down newtype) Deadline: now+2 weeks = 2008-10-20 Questions: 1. should sortOn be added to Data.List? 2. should all other *On functions be added as well? 3. what name should these functions get? 4. should the sortOn' variations be added? What about the naming? 5. should Down be added to Data.Ord? Note: The addition of sortOn was previously proposed as #2406 and rejected because it did not follow the library submission guidelines. Twan [1] http://www.google.com/codesearch?q=lang%3Ahaskell+sortBy [2] http://research.microsoft.com/~simonpj/papers/list-comp/index.htm

11 15

2008-10-13 Hackage status with GHC 6.10 release candidate
by Don Stewart 14 Oct '08

14 Oct '08

Hey all. The GHC 6.10 RCs are out, and we're preparing the release of GHC proper. To help manage the transistion to GHC 6.10 it is now possible to actually build all the 3rd party Haskell packages, and publish their results wrt. the release candidate. For the first time ever, we're able to have all the 3rd party code tested and ready to go *prior* to the release of the new compiler and base libraries. Using GHC 6.10 RC from today, Cabal 1.6 and cabal-install 1.16, of 682 libraries and apps tried in total, 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 68 DependencyFailed 122 BuildFailed 469 InstallOk Since yesterday, * dependency failures have reduced by 5 * build failures have reduced by 10 * total successfully installed packages are **up by 14** These new packages now all build ok with the GHC 6.10 release candidate, Graphalyze-0.4 alsa-midi calc glome-hs harpy heap hmp3 ircbouncer mohws panda pandoc roguestar-engine type-level typeof unicode-prelude urlcheck Good work everyone! Some packages are still not ready though, if you maintain one of the following packages, and are able to fix it before GHC 6.10 is released, your users will be happy. The most common issues for these differences are, * Changes to Arrow class definition * Changes to types of Map and Set functions * Cabal changes * Changes to ghc-api * Changes to when 'forall' is parsed (add Rank2Types) * GHC.Prim was moved, * Changes to -fvia-C and headers * GADT changes, * pragma warnings tightened * Integer constructors have moved * New warnings and used -Werror The following packages are still producing different results than with ghc 6.8.2. Package maintainers are invited to look at them. I've marked the easy ones. ArrayRef-0.1.2 Easy: duplicate type signatures CLASE-2008.9.23.2 Hard: GADT changes EdisonCore-1.2.1.2 Easy: Monadic Map HPDF-1.4 Easy: Monadic Map HaLeX-1.1 Easy: Name clash with permutations Hashell-0.15 ? : GHC API Hipmunk-0.2 Easy: Monadic Map MemoTrie-0.0 Easy: 'forall' parsing NewBinary-0.1.1 Easy: Integer constructors moved PArrows-0.1 Easy: GHC.Prim moved (use GHC.Exts) TypeCompose-0.5 Easy: Arrow class changes YamlReference-0.9.2 Hard. Unknown Yampa-0.9.2.2 Arrow class changes arrows-0.4 Arrow class changes bytestring-show-0.2 Easy: Integer constructors moved cabal-setup-1.2.1 Hard: Cabal changes chp-1.1.0 Easy: Arrow class changes cmath-0.3 Hard: -fvia-C changes fixpoint-0.1 Easy: Uses -Werror unnecessarily hasim-0.1 Hard: GADT changes hask-home-2007.12.6 Easy: Cabal changes hetris-0.2 Easy: header macros/-fvia-C hexpat-0.2 Easy: 'forall' parsing in RULES hinstaller-2008.2.16 Easy: Cabal changes hint-0.2.4.1 Hard? GHC API hslackbuilder-0.0.1 Easy: Cabal changes hxt-8.1.0 Easy: Arrow class change iException-0.0.1 ? Exception changes libGenI-0.16.1 Easy: Monadic Map changes mage-1.1.0 Hard: -fvia-C changes numeric-prelude-0.0.4 Easy: Lanuage pragma plugins-1.3 Easy: Cabal changes quantum-arrow-0.0.4 Easy: Arrow class changes regex-tdfa-0.94 Easy: Map changes streamproc-1.1 Easy: Arrow class changes stringtable-atom-0.0.4 Easy: Monadic Map typalyze-0.1.1 ? GHC API xmonad-utils-0.1 ? GHC API yhccore-0.9 ? Pragma parsing Build reports for everything, produced today, are here, http://galois.com/~dons/tmp/build-logs-2008-10-13/ How to address these, as library maintainers, is addressed here, http://haskell.org/haskellwiki/Upgrading_packages If you'd like to try your own build of all of hackage, grab a package list (such as this one), http://www.galois.com/~dons/tmp/pkgs-6.10 Install a GHC 6.10 release candidate, upgrade to Cabal 1.6 (on hackage), and cabal-install 0.6 (on hackage), and then simply, cabal install -v -O0 $(cat pkgs-6.10) --build-reports This will construct a clever plan to install all the packages in the right order, and write logs to ~/.cabal/logs and a full structured build report into ~/.cabal/packages/hackage.*/build-report.log I'll start mailing maintainers personally tomorrow. -- Don

2 1

Re: [Haskell-cafe] Hackage and GUI (was Hackage status with GHC 6.10 release candidate)
by Duncan Coutts 13 Oct '08

13 Oct '08

On Mon, 2008-10-13 at 16:15 +0200, Hans van Thiel wrote: > What's the status of Gtk2Hs with regard to Cabal? Is it correct that not > one of the applications on Hackage, and there are some, uses or can use > a GUI at this point in time? Gtk2Hs still does not use Cabal as its build system. With the recent summer of code project on a dependency framework for Cabal we're now much closer to being able to convert Gtk2Hs to use Cabal. There are several packages on hackage that depend on gtk2hs or wxhaskell. > Secondly, has Gtk2Hs compatibility been tested with GHC 6.10? In the > past there have sometimes been problems with new GHC releases and > Gtk2Hs. These have always been addressed, but it usually took a few > months.. I think I've seen some patches going past on the gtk2hs-devel list for ghc-6.10 compatibility. Duncan

1 0

2008-10-12 Hackage status with GHC 6.10 release candidate
by Don Stewart 13 Oct '08

13 Oct '08

Hey all. The GHC 6.10 RCs are out, and we're preparing the release. To help manage the transistion to GHC 6.10 it is now possible to actually build all the 3rd party Haskell packages, and publish their results wrt. the release candidate. For the first time ever, we're able to have all the 3rd party code tested and ready to go *prior* to the release of the new compiler and base libraries. Using GHC 6.10 RC, Cabal 1.6 and cabal-install 1.16, of 682 libraries and apps tried in total, 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 73 DependencyFailed 132 BuildFailed 456 InstallOk Note that these builds are with "soft deps", provided on hackage, base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2 which train cabal-install to build a larger set of packages. The important result: *46 packages produce different results to ghc 6.8.2* These packages and their logs are listed below. If you maintain one of the following packages, and are able to fix it before GHC 6.10 is released, your users will be happy. The most common issues for these differences are, * Changes to Arrow class definition * Changes to types of Map and Set functions * Cabal changes * Changes to ghc-api * Changes to when 'forall' is parsed (add Rank2Types) * GHC.Prim was moved, * Changes to -fvia-C and headers * GADT changes, * pragma warnings tightened * Integer constructors have moved * New warnings and used -Werror How to address these, as library maintainers, is addressed here, http://haskell.org/haskellwiki/Upgrading_packages Build reports for everything, produced today, are here, http://galois.com/~dons/tmp/build-logs-2008-10-12/ The following packages are producing different results than with ghc 6.8.2. Package maintainers are invited to look at them. ArrayRef-0.1.2 CLASE-2008.9.23.2 EdisonCore-1.2.1.2 HPDF-1.4 HaLeX-1.1 Hashell-0.15 Hipmunk-0.2 MemoTrie-0.0 NewBinary-0.1.1 PArrows-0.1 TypeCompose-0.5 WebBits-0.9.2 YamlReference-0.9.2 Yampa-0.9.2.2 arrows-0.4 bytestring-show-0.2 cabal-setup-1.2.1 chp-1.1.0 cmath-0.3 fixpoint-0.1 hasim-0.1 hask-home-2007.12.6 hetris-0.2 hexpat-0.2 hinstaller-2008.2.16 hint-0.2.4.1 hslackbuilder-0.0.1 hxt-8.1.0 iException-0.0.1 libGenI-0.16.1 list-extras-0.2.2 logfloat-0.9.1 mage-1.1.0 numeric-prelude-0.0.4 plugins-1.3 quantum-arrow-0.0.4 regex-tdfa-0.94 streamproc-1.1 stringtable-atom-0.0.4 typalyze-0.1.1 xmonad-utils-0.1 yhccore-0.9 If you'd like to try your own build of all of hackage, grab a package list (such as this one), http://www.galois.com/~dons/tmp/pkgs-6.10 Install a GHC 6.10 release candidate, upgrade to Cabal 1.6 (on hackage), and cabal-install 0.6 (on hackage), and then simply, cabal install -v -O0 $(cat pkgs-6.10) --build-reports This will construct a clever plan to install all the packages in the right order, and write logs to ~/.cabal/logs and a full structured build report into ~/.cabal/packages/hackage.*/build-report.log -- Don

3 3