- Libraries - Haskell.org

Cabal: literate hscolour
by Sean McLaughlin 24 Aug '09

24 Aug '09

Hello, I can't find a way to pass the -lit flag to hscoulour using neither my cabal configuration file nor a command line option to runhaskell Setup.hs haddock. I'd really like to not have my literate comments be colored according to Haskell lexical conventions. Is there a way to do this? Thanks! Sean

3 8

Question of HP updates that depend on new packages
by Duncan Coutts 21 Aug '09

21 Aug '09

All, A requirement of packages in the platform is that all dependencies of packages also be in the platform (excluding C libs). When an updated version of an existing platform package includes dependencies on packages that are currently outside the platform we must decide if those packages are to be added to the platform (or if we must stick with the older version of the package). Sometimes this will be trivial, such as if a package splits in two but keeps essentially the same API and module namespace. Sometimes it would means pulling in new packages. Normally new packages should go through the standard process for adding packages [Note: currently, the HP steering committee is nearly ready to present a draft of the procedure for adding new packages.] The case of the OpenGL 2.2.x -> 2.3 update covers both cases above. That is it includes straightforward package splits and also new packages. The last HP release included OpenGL-2.2.1.1. The latest version on hackage is OpenGL-2.3.0.0. OpenGL-2.2.x depends on the base package. OpenGL-2.3.0.0 depends on these extra packages: OpenGLRaw GLURaw ObjectName StateVar Tensor The first two are relatively straightforward. The OpenGL package has modules in the namespace Graphics.Rendering.OpenGL. The OpenGLRaw and GLURaw add modules in the namespaces Graphics.Rendering.OpenGL.Raw and Graphics.Rendering.GLU.Raw. One can easily class these new packages as merely split from the OpenGL package and this does not need much review. The other three packages are: package: ObjectName modules: Data.ObjectName package: StateVar modules: Data.StateVar package: Tensor modules: Data.Tensor These add new modules in the common Data.* namespace, indicating that they are intended for re-use more widely by other packages. The release team should not make a decision on these three packages on its own. We wish to refer these packages to the libraries list for a decision. In particular the libraries list should decide if these new packages should be rubber stamped because they are new dependencies of a package already in the platform, or if the new packages should go through the standard review process for adding packages. Duncan, on behalf of the HP release team

5 8

Re: Ticket #3271: New methods for Data.Sequence
by Louis Wasserman 20 Aug '09

20 Aug '09

Ross, This new version<http://hackage.haskell.org/trac/ghc/attachment/ticket/3271/new-methods-for-…>should fix your concerns. Is there anything else? Louis Wasserman wasserman.louis(a)gmail.com

2 1

proposal #3335: make some Applicative functions into methods, and split off Data.Functor
by Ross Paterson 19 Aug '09

19 Aug '09

The proposal is that the following functions (<$) :: Functor f => a -> f b -> f a (*>) :: Applicative f => f a -> f b -> f b (<*) :: Applicative f => f a -> f b -> f a some :: Alternative f => f a -> f [a] many :: Alternative f => f a -> f [a] are moved into the corresponding classes, with the existing implementations as default definitions. This gives people creating instances the option of defining specialized implementations of these functions, though they should be equivalent to the default definitions. Although (<$) is now a method of the Functor class, it is hidden in the re-export by the Prelude, Control.Monad and Monad. The new module Data.Functor exposes the full class, plus the function (<$>). These are also re-exported by Control.Applicative. Deadline: 20th July 2009.

7 24

Re: Proposal #3271: new methods for Data.Sequence
by Louis Wasserman 19 Aug '09

19 Aug '09

Fixed. Is there anything else? Louis Wasserman wasserman.louis(a)gmail.com

2 1

hasktags enhancements ? How to contribute?
by Marc Weber 18 Aug '09

18 Aug '09

Hi, more than a year ago I enhanced hasktags. Now I had another look at my code ensuring that it finds at least as many tags as the hackage implementation does. It also adds a small test suite ensuring progress. So let me know how well it works for you. If some tags aren't found send me a test case so that I can add it to the test suite. Where to get it from: darcs get http://mawercer.de/~marc/my-hasktags So what's different ? - it finds more tags (see details below) - it adds tag kinds (vim only) Example: SpacingCombiningMark ./2/testcase2.hs 154;" cons Surrogate ./2/testcase2.hs 175;" cons TitlecaseLetter ./2/testcase2.hs 150;" cons UppercaseLetter ./2/testcase2.hs 148;" d digitToInt ./2/testcase2.hs 131;" ft digitToInt ./2/testcase2.hs 132;" fi cons = contstructor ft = funtion type fi = function implementation m = module - adds the flag --ignore-close-implementation eg if you have abc,def :: Int abc = 7 {- 20 line comment .. -} def = 8 abc is added once (because the type definition and the implementation is very close) but def is added twice because you may want to jump to either one directly. That's important because :tjump (vim) won't bother you asking you which one to take. So the list of tags is shorter in general. details about finding more tags: a) it finds more tags -> [1] Example (by testcase) 1) module Main where import Text.JSON func = ... using this strange indentation the hackage hasktags fails horribly (test case 1) 2) from Data.Char #ifndef __GLASGOW_HASKELL__ isAsciiUpper, isAsciiLower :: Char -> Bool isAsciiLower c = c >= 'a' && c <= 'z' isAsciiUpper c = c >= 'A' && c <= 'Z' #endif this isAsciiUpper isn't found by the hackage version for some reason 4) the basic rootLoggerName isn't found! module System.Log.Logger rootLoggerName = "" 5) Saying those aren't found isn't quite true. the hackage version just doesn't remove the parenthesis and adds (@?) to the tag file. 8) ABCD isn't found because of this parenthesis class (Show a) => (ABCD a) where Again (ABCD is found instead. You can test this yourself by running my testsuite (cd testcases; sh test.sh) Marc Weber

1 1

proposal for updates in next major HP release
by Duncan Coutts 17 Aug '09

17 Aug '09

All, The previous decision[1] of the libraries list is that major HP releases are to be on a 4 month cycle for at least the first 12 months. [1]: http://trac.haskell.org/haskell-platform/wiki/Policy That means we're aiming for the next major release being in early September, about a month away from now. This email is to propose "obvious" updates. We hope these are not controversial and that we can quickly get an OK. We suggest updating each package to its latest stable release, except where noted below. In most cases this means relatively insignificant API changes. The cases of particular interest are: regex-* packages updated from 0.7x versions to 0.9x versions QuickCheck update from version 1.2.x to version 2.x We are not proposing to switch to parsec-3.x at this time. This proposal does not cover updates to the OpenGL package(s). Remove editline package Remove packedstring package The rationale for removing editline is that it is no longer used by ghc. It was only included in the platform in the first place because early releases of ghc-6.10.x shipped it as a core library. The rationale for removing packedstring is that is has been deprecated for some years now. It was only included in the platform because the template-haskell package still depended on it. The latest version of template-haskell no longer requires it. Duncan (on behalf of the HP release team)

9 12

(no subject)
by roconnor＠theorem.ca 17 Aug '09

17 Aug '09

According to <http://www.haskell.org/hierarchical-modules/libraries/reference-libraries.h…> I'm supposed to ask here for bits of heirarchy. I have no idea if this is still the procedure. As far as I know nobody follows this procedure. But I could just be ignorant. :) I'd like Data.Colour for my colour package: <http://hackage.haskell.org/package/colour> I should point out that <http://hackage.haskell.org/package/AC-Colour> also used Data.Colour, so there is a conflict to be resolved here. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

5 7

Haskell Platform: Changelogs and "available since"
by Ian Lynagh 17 Aug '09

17 Aug '09

Hi all, Reading a thread in -cafe made me think of another couple of requirements to consider for platform packages: * A changelog for the package is maintained * In the documentation for each function etc, the first version to support the feature is given. Thanks Ian

5 5

Re: Adding an ignore function to Control.Monad
by John Lato 14 Aug '09

14 Aug '09

> From: Henning Thielemann <lemming(a)henning-thielemann.de> > > Isaac Dupree schrieb: >> On the other hand, maybe it's also an argument to change all the >> functions like forkIO from >> :: IO () -> IO ThreadID >> to >> :: IO a -> IO ThreadID >> >> I mean, surely they don't rely on the value of a () return-type, other >> than to pass on to other places that artificially require the ()-type? > > No, I think it is already bad enough, that (>>) has type (m a -> m b -> > m b) instead of (m () -> m b -> m b). It is like automatically ignoring > return values in C. It is too easy to ignore a result that is important. I agree with Henning on forkIO and the like, but I think the current type of (>>) is right. The name of the function is "anonymous bind" (at least that's what I learned), and its whole purpose of existence is to ignore the value of the first computation while maintaining the context. It would be nice if there were greater differentiation between (>>) and (>>=), though. Ideally, (>>) would be changed to something longer than (>>=) to prevent accidental mis-typing (i.e. on the keyboard). Not that I expect much support for this proposal! John

12 25