- Libraries - Haskell.org

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 04 Nov '06

04 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

patch to add image routines to x11 library
by Frederik Eaton 03 Nov '06

03 Nov '06

Hi all, I've attached a simple patch. There is also a Trac ticket: http://hackage.haskell.org/trac/ghc/ticket/982 Thanks, Frederik -- http://ofb.net/~frederik/

1 0

Re: [GHC] #971: Add intercalate and split to Data.List
by Christian Maeder 02 Nov '06

02 Nov '06

> = Split = > Bulat Ziganshin suggested also adding a function split which is a right > inverse of intercalate. Donald Steward seemed to agree with this decision. > No one else raised their voice about this so it seems uncontroversial. I also agree to add a split function. The problem was to agree which variant should be called split (wrt. to treatment of multiple and final separators as well as to "Eq" context or predicate argument). http://article.gmane.org/gmane.comp.lang.haskell.libraries/4862 http://article.gmane.org/gmane.comp.lang.haskell.libraries/4869

6 8

darcs patch: Adding isLeft, isRight, fromLeft, fromRight, splitEithers
by Russell O'Connor 01 Nov '06

01 Nov '06

Mon Oct 30 14:28:19 CET 2006 Russell O'Connor <roconnor(a)theorem.ca> * Adding isLeft, isRight, fromLeft, fromRight, splitEithers This patch resolves http://hackage.haskell.org/trac/ghc/ticket/974 Spam detection software, running on the system "smeltpunt.science.ru.nl", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see postmaster(a)science.ru.nl for details. Content preview: Mon Oct 30 14:28:19 CET 2006 Russell O'Connor <roconnor(a)theorem.ca> * Adding isLeft, isRight, fromLeft, fromRight, splitEithers This patch resolves http://hackage.haskell.org/trac/ghc/ticket/974 New patches: [...] Content analysis details: (5.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.7 INFO_TLD URI: Contains an URL in the INFO top-level domain 3.6 BAYES_80 BODY: Bayesian spam probability is 80 to 95% [score: 0.8821]

9 16

package mounting
by Frederik Eaton 31 Oct '06

31 Oct '06

Hi lists, I recently read Simon Peyton Jones' proposal: http://hackage.haskell.org/trac/ghc/wiki/GhcPackages and disagreed with some of the design decisions. (To be fair, the aspects I disagree with are shared with most or all of the other proposals) So I've put an alternative proposal here: http://hackage.haskell.org/trac/ghc/wiki/PackageMounting Discussion is welcome (but only on the libraries@ list, please). Hopefully we can weigh the benefits of each proposal, and reach an agreement and write up a more formal specification within the next few months or so provided that people decide that this is an extension we want to implement. Cheers, Frederik P.S. (I'm sorry that I missed Sven's earlier package mounting thread in July. But I hope the above article covers what my response would have been) -- http://ofb.net/~frederik/

7 14

Cabal 1.1.6: an infelicity and a bug
by Gregory Wright 31 Oct '06

31 Oct '06

Hi, I've been updating the various haskell ports in MacPorts and have found a couple of problems with the latest Cabal (1.1.6, as provided by ghc-6.6). One is simply an infelicity that adds unnecessary work: why does ./Setup register fail with an error when used with an application that installs no libraries? Could it simply return success and an informational message like, "No library to install"? As it is, the user (or the person building the package) needs to know if a library is installed or not. It's not a big deal in the case of packages which just provide libraries, but it creates a difference in installation procedure for packages that only provide applications and those that provide applications along with libraries. (For an application, the script version of registration, ./Setup register --gen-script, should just generate a stub that returns success, too.) Having register simply return success for an application also makes the library and application installation procedures identical. From my experience in building packages, the more uniform the installation procedure, the better. The second problem I found is more serious. When installing a library, in this case MissingH 0.16, I get the error: ghc-pkg: /opt/local/lib/MissingH-0.16.0/ghc-6.6/include doesn't exist or isn't a directory (use --force to override) Error: Target com.apple.activate returned: shell command "/opt/local/ libexec/missingh/register.sh" returned error 1 Command output: Reading package info from stdin ... done. ghc-pkg: /opt/local/lib/MissingH-0.16.0/ghc-6.6/include doesn't exist or isn't a directory (use --force to override) Warning: the following items did not execute (for missingh): com.apple.activate Error: Status 1 encountered during processing. crossroads-able> (the above is the output of the MacPorts portfile.) The problem is that when the build is staged into a temporary location so the files can be inventoried, an empty directory, <prefix>/lib/MissingH-0.16.0/ghc-6.6/include is created. MacPorts deletes this empty directory (along with a number of other unused directories it creates in the staging process). The registration process requires the empty directory to be present and fails, as shown above, if it is not. The solution is simple: cabal can to drop a small file into any directory it needs, say ".cabal-turd", preventing it from being deleted (This is most easily done from the cabal side, rather than the packaging system side, since the path has the haskell compiler and version coded into it.) I know that a case can be made for packaging systems preserving all the directories created by a package, even empty ones. However, Macports (formerly darwinports) and cabal played nicely in the past and the 1.1.6 behavior breaks this. Best Wishes, Greg

1 0

A Pointless Library Proposal
by Conor McBride 31 Oct '06

31 Oct '06

Hi folks This seems like the ideal time to make a wannabe library proposal which is pointless, but pointless by design. The code's quite short: ---------- > module Zero where > -- import GHC.Prim -- if you can The Zero type has nothing in it. Well, nothing worth worrying about anyway. > data Zero Elements of Zero are rather special, powerful things. > magic :: Zero -> a > magic _ = error "There's magic, as no such thing!" It's a little frustrating to have to define this function lazily. I prefer the strict definition with no lines, but it isn't valid Haskell! The main use of Zero is to give types |f Zero| to the closed ('elementless') values of some functorial structure f, especially closed /terms/. These closed values should be embedded (as cheaply as possible) into all the f-types which do permit elements. > fMagic :: Functor f => f Zero -> f a > fMagic = fmap magic -- if you must > -- fMagic = unsafeCoerce# -- if you can ----------- I'm not being facetious here. The reason it ought to be in a library rather than ad hoc is that it (ideally) packs up a perfectly safe use of unsafeCoerce#, which deserves some veneer of legitimacy. This is seriously useful stuff if you want better static checking for scope (and related notions), without taking a performace hit. For example, you should all know the classic de Bruijn representation... > data Tm x = V x | A (Tm x) (Tm x) | L (Tm (Maybe x)) deriving Show ...for which fmap does renaming... > instance Functor Tm where > fmap rho (V x) = V (rho x) > fmap rho (A f a) = A (fmap rho f) (fmap rho a) > fmap rho (L b) = L (fmap (fmap rho) b) ...and (>>=) does capture-avoiding simultaneous substitution. > instance Monad Tm where > return = V > V x >>= sgm = sgm x > A f a >>= sgm = A (f >>= sgm) (a >>= sgm) > L b >>= sgm = L (b >>= shift sgm) where > shift sgm Nothing = V Nothing > shift sgm (Just x) = fmap Just (sgm x) But operationally, you'd never do any such thing. See how capture is avoided? The shift operator (aka traverse, but that's another story), has to tweak all the free variables in the image of the substitution to avoid capturing the new bound variable, Nothing. Ouch! However, if you've ever fooled around with Int-based de Bruijn representations, you'll know that the really cool thing is to substitute /closed/ terms without any need for shifting. A term with no free variables can't capture anything! Hence > closedSubst :: (x -> Either (Tm Zero) y) -> Tm x -> Tm y > closedSubst sgm (V x) = either fMagic V (sgm x) > closedSubst sgm (A f a) = A (closedSubst sgm f) (closedSubst sgm a) > closedSubst sgm (L b) = L (closedSubst (shift sgm) b) where > shift sgm Nothing = Right Nothing > shift sgm (Just x) = either Left (Right . Just) (sgm x) Here, variables are either mapped to closed terms or renamed. We never need to traverse the closed terms to push them under a binder: the shift operator (aaka traverse, ahem) only shifts the renaming part (cheap!) and the closed terms stay closed. When we finally hit a variable, the closed images just get fMagic'd into the right scope! So there you have it, a bone fide useful use of the Zero type, given a module exporting a safe use of a usually dodgy operator. I don't think module Zero is as pointless as the the datatype it defines. My apologies for not providing any QuickCheck properties. All the best Conor This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

21 43

darcs patch: UNDO: Inline shift in GHC's Bits instanc... (and 1 more)
by Samuel Bronson 30 Oct '06

30 Oct '06

Sun Oct 8 22:09:06 EDT 2006 Samuel Bronson <naesten(a)gmail.com> UNDO: Inline shift in GHC's Bits instances for {Int,Word}{,8,16,32,64} 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?

1 0