November 2006 - Libraries

unsafeShift operations for Data.Bits
by Bulat Ziganshin 10 Nov '06

10 Nov '06

Hello libraries, fast shift operations that don't verify shift amount is rather popular demand. how about providing them in the Data.Bits? -- |Shifts its first operand left by the amount of bits specified in -- second operand. Result of shifting by negative/too large amount -- is not specified. Should be used only in situations when you may -- guarantee correct value of second operand or don't care about result :) unsafeShiftL :: Int -> Int -> Int unsafeShiftR :: Int -> Int -> Int #ifdef __GLASGOW_HASKELL__ unsafeShiftL (I# a) (I# b) = (I# (a `iShiftL#` b)) unsafeShiftR (I# a) (I# b) = (I# (a `uncheckedIShiftRL#` b)) #else /* ! __GLASGOW_HASKELL__ */ unsafeShiftL = shiftL unsafeShiftR = shiftR #endif /* ! __GLASGOW_HASKELL__ */ it may be even better to include them in Bits class with obvious default definition -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

5 9

Guidelines for proposing library changes
by dons＠cse.unsw.edu.au 10 Nov '06

10 Nov '06

After some discussion on the libraries list, I've put up the suggested 'best practice' for proposing library changes, here: http://haskell.org/haskellwiki/Library_submissions The idea is to reduce the number of 'bikeshed' discussions we're having, ensure that submissions are not dropped, and generally improve productivity. People should refer to this when proposing new functions for the core libraries, at risk of not having the suggestion adopted or considered ;) Cheers, Don

9 21

Proposal discussion summary: Adding on
by Nils Anders Danielsson 09 Nov '06

09 Nov '06

The deadline for discussion is tomorrow, but in case anyone complains I thought I'd summarise the previous discussion already today. * Consensus was reached that a module containing on plus some functions from the prelude should be added. * The module name Control.Function was not well received. A bunch of other names were suggested, and almost everyone accepted Data.Function. * It was discussed whether comparing (i.e. on compare) and/or equating (on (==)) should also be present in the libraries. Consensus was reached that either both or none of them should be there, and most people wanted to have them in the libraries. The function comparing is already in the libraries, but not equating. Complaints were raised about the name "equating", though, and no consensus was reached about an alternative name. Hence I leave the comparing/equating discussion open for another proposal. -- /NAD

5 5

Re: [Haskell-cafe] Re: ANN: System.FilePath 0.10
by Neil Mitchell 08 Nov '06

08 Nov '06

Hi Ashley, > How do I manipulate a Windows file path on a POSIX machine (something > relating to Samba, for instance)? import System.FilePath.Windows This will give you windows FilePath handling regardless of your operating system. (in the same way System.FilePath.Posix will give you Linux style filepaths, and System.FilePath will give you the appropriate type based on your OS) Thanks Neil

1 0

Proposal: Adding on
by Nils Anders Danielsson 08 Nov '06

08 Nov '06

The function on defined by (*) `on` f = \x y -> f x * f y is convenient when using functions like sortBy: sortBy (compare `on` fst), for example. It also makes the code more readable. Furthermore I consider on to be above the Fairbairn threshold, since * we get rid of two lambdas, * we get rid of the duplication of p, * on has some nice algebraic properties (documented in the patch) * and, most importantly, it is easier at a glance to understand (*) `on` p than to understand \x y -> p x * p y (assuming one knows about on). The main question seems to be which module to put the function in. Based on previous discussion on the libraries list I suggest creating a new module Control.Function containing on plus (initially) some other combinators (working solely on and with functions) from the Prelude. Deadline for discussion: 2006-11-09. Trac ticket number: 979. -- /NAD

13 30

darcs patch: Use unchecked shifts to implement Data.Bits.rotate
by Samuel Bronson 07 Nov '06

07 Nov '06

Thu Oct 12 08:55:53 EDT 2006 Samuel Bronson <naesten(a)gmail.com> * Use unchecked shifts to implement Data.Bits.rotate This should get rid of those cases, maybe lower the size enough that the inliner will like it?

2 2

Re: [Haskell-cafe] RFC and Announcement: HLADSPA, LADSPA for Haskell
by Ross Paterson 07 Nov '06

07 Nov '06

On Mon, Nov 06, 2006 at 10:43:05PM +1100, Donald Bruce Stewart wrote: > I agree, and would remark for anyone reading: > > Please add your projects, whether they are applications, libraries, > tools, darcs repos, to : > > http://haskell.org/haskellwiki/Libraries_and_tools > > *All* Haskell code that's available, and fit to compile should be > findable from that page. It would also be useful to get software packaged with Cabal into http://hackage.haskell.org/packages/unstable/ This collection isn't used for much yet, except an experimental web interface at http://hackage.homedns.org/view/ and there are some nearly-finished tools. In the meantime, if we have the packages collected in one place people can run all sorts of tests over them. It seems there's no general way to upload packages yet, but those with logins on hackage.haskell.org can say cabal-put PACKAGE-VERSION.tar.gz (where the tar file contains a directory PACKAGE-VERSION containing PACKAGE.cabal.) Those who don't can ask those who do.

1 0

map* for Data.List
by Bulat Ziganshin 06 Nov '06

06 Nov '06

Hello libraries, similar to mapFst and Co, we can define: -- |Map various parts of list mapHead f [] = [] mapHead f (x:xs) = f x : xs mapTail f [] = [] mapTail f (x:xs) = x : map f xs mapInit f [] = [] mapInit f xs = map f (init xs) : last xs mapLast f [] = [] mapLast f xs = init xs : map f (last xs) btw, two last operations may be a bit slow. it's possible to define initLast function that returns both parts and still lazy? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

8 9

Speaking of small functions
by Cale Gibbard 03 Nov '06

03 Nov '06

Speaking of small functions, Kleisli composition should at least be in Control.Monad. It's a simple thing, and not commonly explicitly used at the moment, but rather important conceptually. (@@) :: (Monad m) => (b -> m c) -> (a -> m b) -> (a -> m c) g @@ f = \x -> f x >>= g

12 14

hs-plugins: dynamic linking error with .ctors section
by Cyril Schmidt 03 Nov '06

03 Nov '06

I am using hs-plugins to load some Haskell modules dynamically. It all goes well until I try to load a module that uses a package with some C++ code in the implementation. The module in question, A.hs, uses a package named RGPack, which consists of some C++ code and a single Haskell module that provides the necessary `foreign import' declarations. The package (including the C++ code) is built by GHC. When I try to load A.hs using hs-plugins, I get the following error: Unknown PEi386 section name `.ctors' (while processing: C:\Program Files\Haskell\RGPack-0.0\ghc-6.4.2/HSRGPack-0.0.o) When I link A.hs statically (using `import A' in my main module), it works fine. I am fairly sure that the problem is somehow related to the usage of the C++ code in the package (because .ctors section is C++-specific), but I have no idea how I can remedy this. Rewriting the C++ code to pure C is an obvious workaround, but I'd prefer to try something else before I resort to this ;-) For the record, I use GHC 6.4.2 on Windows, hs-plugins-1.0-rc0. I will greatly appreciate any hints. Cheers, Cyril

3 4