January 2010 - Haskell-Cafe

hsql won't install due to system.time
by Brian Denheyer 23 Jan '10

23 Jan '10

Database/HaskellDB/HSQL.hs:25:7: Could not find module `System.Time': it is a member of the hidden package `old-time-1.0.0.3' it is a member of the hidden package `old-time-1.0.0.2' Use -v to see a list of the files searched for. old-time-1.0.0.2 is installed (via cabal). Suggestions on how to fix this or which haskell db (for sqlite3) package will actually install greatly appreciated. I get a lot of failures in hackages which involve that dreaded "hidden package" message. Anybody care to enlighten us mere mortals as to why it seems to occur so frequently (at least for me). Brian

4 7

ghci debugger, can't set breakpoint
by Mike Burrell 23 Jan '10

23 Jan '10

I recently upgraded from GHC 6.8.2 to GHC 6.10.4 and can no longer set breakpoints the way I'm used to. It seems I can only set breakpoints in the current module. I Googled around and found someone with a similar error message trying to load modules which aren't interpreted, but that's not the case for me as all modules are interpreted. Here's me loading the TypeInference module (where I want to set the breakpoint) directly and having it work. Then I load the Main module and try to set the breakpoint in TypeInference with no luck. Am I setting breakpoints wrong here? Any help would be appreciated. Cheers, Mike 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. Prelude> :l TypeInference [1 of 3] Compiling Utility ( Utility.lhs, interpreted ) [2 of 3] Compiling Parser ( Parser.hs, interpreted ) Parser.hs:1897:1: Warning: Pattern match(es) are overlapped In a case alternative: _ -> ... [3 of 3] Compiling TypeInference ( TypeInference.lhs, interpreted ) Ok, modules loaded: Parser, TypeInference, Utility. *TypeInference> :break 823 Breakpoint 0 activated at TypeInference.lhs:823:10-14 *TypeInference> :l Main [1 of 7] Compiling Utility ( Utility.lhs, interpreted ) [2 of 7] Compiling Parser ( Parser.hs, interpreted ) Parser.hs:1897:1: Warning: Pattern match(es) are overlapped In a case alternative: _ -> ... [3 of 7] Compiling TypeInference ( TypeInference.lhs, interpreted ) [4 of 7] Compiling Bounds ( Bounds.lhs, interpreted ) [5 of 7] Compiling Interpreter ( Interpreter.lhs, interpreted ) [6 of 7] Compiling PatternMatching ( PatternMatching.lhs, interpreted ) [7 of 7] Compiling Main ( Main.lhs, interpreted ) Ok, modules loaded: Parser, TypeInference, Utility, Main, Bounds, PatternMatching, Interpreter. *Main> :break TypeInference 823 No breakpoints found at that location. *Main>

1 0

Type level splices and instance deriving
by Khudyakov Alexey 23 Jan '10

23 Jan '10

Hello GHC 6.12 introduced type level splices. They are great for instances generation. They allow for much clearer and easier to understand code. However I run into problem with them. It's possible to create instance for type class which doesn't have superclass. If it does have one compiler complains that it could not deduce context. All my attempts to provide context fail. Is that accidental limitation or because of Some Good Reason? Or just due to lack of understanding on my side? Below is simplest example. > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE TemplateHaskell #-} > import Language.Haskell.TH > > -- OK but require FlexibleInstances > makeEq :: Name -> Q [Dec] > makeEq name = > [d| instance Eq $(conT name) where > (==) = undefined > |] > > -- Could not deduce Eq context > makeOrd :: Name -> Q [Dec] > makeOrd name = > [d| instance Ord $(conT name) where > compare = undefined > |] And GHC output: test.hs:14:17: Could not deduce (Eq t) from the context () arising from the superclasses of an instance declaration at test.hs:14:17-32 Possible fix: add (Eq t) to the context of the instance declaration In the instance declaration for `Ord t_aS5' In the Template Haskell quotation [d| instance Ord $(conT name) where { compare = undefined } |] In the expression: [d| instance Ord $(conT name) where { compare = undefined } |] -- Khudyakov Alexey

1 0

ANNOUNCE: Updates and a new member of the Monadic Regions family
by Bas van Dijk 23 Jan '10

23 Jan '10

Hello, I released updates of all the members of the Monadic Regions family: * http://hackage.haskell.org/package/regions-0.3 - Export the 'Dup' and 'ParentOf' classes from 'Control.Monad.Trans.Region'. - Add: 'mapInternalHandle ∷ (Handle resource1 → Handle resource2) → (RegionalHandle resource1 r → RegionalHandle resource2 r)'. - Internal refactoring. * http://hackage.haskell.org/package/regions-monadsfd-0.3 * http://hackage.haskell.org/package/regions-monadstf-0.3 * http://hackage.haskell.org/package/usb-safe-0.5.1 - No major changes in these packages just internal refactoring and support for regions-0.3.*. * http://hackage.haskell.org/package/safer-file-handles-0.3 - 'File' is turned into a GADT, it's parameterized with the IOMode and its constructors are exported. - Added support for bytestring IO. - Internal refactoring. * http://hackage.haskell.org/package/explicit-iomodes-0.2 This package is not a member of the family but it is required for 'safer-file-handles'. I released an update which: - Added support for bytestring IO. - Internal refactoring. Additionally I would like to announce a new member of the family: * http://hackage.haskell.org/package/regional-pointers-0.1 to quote the description: "The library allows you to allocate memory in a region yielding a regional pointer to it. When the region terminates all pointers are automatically freed. Most importantly, a pointer can't be returned from the region. So it's impossible to reference unallocated memory." This package need some more work (primarily documentation and testing) so I consider it a beta release. Note that the darcs repositories for all packages are not updated because I can't seem to get a SSH connection with code.haskell.org :-( Happy Haskell Hacking, Bas

1 1

http://trac.haskell.org down?
by James Britt 22 Jan '10

22 Jan '10

Been trying to reach http://trac.haskell.org for most of the morning, but nothing comes up. Seems I'm not alone: http://downforeveryoneorjustme.com/http://trac.haskell.org James -- Neurogami - Smart application development http://www.neurogami.com james(a)neurogami.com

4 3

GHC bug? Cabal bug? Haddock bug?
by Mark Lentczner 22 Jan '10

22 Jan '10

=== Short Story === If I build syb-with-class-0.6 via cabal (cabal configure; cabal build) in the unpacked tar directory, it builds correctly. If I build it via "cabal install" (either from the unpacked directory, or by letting cabal fetch it), then the resulting package is corrupted. In particular, the .hi interface file for Data.Generics.SYB.WithClass.Instances mentions symbols that aren't in the .a file. (Or rather, they have the wrong names.) I compared verbose logs of both builds and the differ only in temporary file names.... execpt that the "cabal install" version builds haddock, as my .cabal/conf file has documentation: True. Turns out that if turn documentation off, then then "cabal install" builds a .hi file that matches the .a file... and all is well. Is this a bug in cabal? cabal-install? ghc? haddock? I have saved logs of all this if anyone wants. - Mark (MtnViewMark) Lentczner markl(a)glyphic.com http://www.ozonehouse.com/mark/ === Versions === [2373] : cabal -V cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library [2374] : ghc -V The Glorious Glasgow Haskell Compilation System, version 6.10.4 [2376] : ghc-pkg describe haddock | grep version version: 2.4.2 === Background & Details === I was installing happstack on my Mac with my Haskell Platform (GHC 6.10.4) installation. I have successfully installed dozens of other packages in this environment before, and these results are annomalous. I kicked this off via: cabal install --user happstack This installs many packages, including syb-with-class-0.6, which compiled and installed just fine. When installing happstack-data, and compiling the file Happstack/Data/Proxy.hs, during the Template Haskell step (where things get loaded up in ghci), the build encounters this link error: [ 7 of 16] Compiling Happstack.Data.Proxy ( src/Happstack/Data/Proxy.hs, dist/build/Happstack/Data/Proxy.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.5 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package syb-with-class-0.6 ... linking ... done. (... many more loads elided...) Loading package HaXml-1.13.3 ... linking ... done. ghc: unknown symbol `_sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZMabOQZN_closure' That symbol decodes to something referring to: package: syb-with-class-0.6 module: Data.Generics.SYB.WithClass.Instances reference: dataType[abOQ] The reference turns out to be from Loading Happstack.Data.Default, which in turn imports Data.Generics.SYB.WithClass.Instances. Poking around, I found that the interface (.hi) file for Data.Generics.SYB.WithClass.Instances does indeed export such an object: [2324] : ghc --show-iface Data/Generics/SYB/WithClass/Instances.hi | fgrep dataType[a Data.Generics.SYB.WithClass.Instances.dataType[abOQ]) -} Data.Generics.SYB.WithClass.Instances.dataType[abSm]) -} dataType[abOQ] :: Data.Generics.SYB.WithClass.Basics.DataType dataType[abSm] :: Data.Generics.SYB.WithClass.Basics.DataType But, the library doesn't export it: [2325] : nm libHSsyb-with-class-0.6.a | fgrep dataTypeZMa 0001854c D _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZMaeuiZN_closure 00018604 D _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZMaexTZN_closure These refer to dataType[aeui] and dataType[aexT], which don't exist in the interface file. Something seems amiss here: The interface file is exporting generated names that don't match what the library is exporting. If I do the same investigation with the profiling versions of this module, they match: [2326] : ghc --show-iface Data/Generics/SYB/WithClass/Instances.p_hi | fgrep dataType[a Data.Generics.SYB.WithClass.Instances.dataType[anmx]) -} Data.Generics.SYB.WithClass.Instances.dataType[anq8]) -} dataType[anmx] :: Data.Generics.SYB.WithClass.Basics.DataType dataType[anq8] :: Data.Generics.SYB.WithClass.Basics.DataType markl@mtree ~/Library/Haskell/packages/syb-with-class-0.6/lib/ghc-6.10.4 [2327] : nm libHSsyb-with-class-0.6_p.a | fgrep dataTypeZMa 00032704 D _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZManmxZN_closure 0003282c D _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZManq8ZN_closure These both export something dataType[anmx] and dataType[anq8] These two objects, by the way, stem from the last two lines of Data.Generics.SYB.WithClass.Instances.hs: $( deriveData [''ByteString] ) $( deriveData [''L.ByteString] )

3 5

classes with types which are wrapped in
by Andrew U. Frank 22 Jan '10

22 Jan '10

i encounter often a problem when i have a class with some operations (say class X with push) applied to a type A b. I then wrap A in a type A_sup, with some more type parameters and i cannot write a instance of class A_sup because i have a kind mismatch. any suggestions? (reordering of the type parameters of A_sup is not a solution, because another class operates on this parameter) here a simplistic case (i know that A could be reduced to [], my real cases are more complicated). data A b = A b [b] data Asup x ab y = Asup x ab y class X a b where push :: b -> a b -> a b instance X A Int where push b' (A b bs) = A b' (b:bs) instance X Asup Char Int Float where push b' (Asup a b c) = Asup a (push b' b) c -- this does not compile because the number of type arguments for X is wrong. if i try with a type type A_2 b = Asup Char (A b) Float instance X A_2 Int where push b' (Asup a b c) = Asup a (push b' b) c (and --TypeSynonymInstances) i get: Type synonym `A_2' should have 1 argument, but has been given 0 In the instance declaration for `X A_2 Int' what is the solution? thank you! andrew

5 4

Existential Types (I guess)
by Ozgur Akgun 22 Jan '10

22 Jan '10

Dear Cafe, I can write and use the following, data IntHolder = IntHolder Integer instance Show IntHolder where show (IntHolder n) = show n liftInt :: (Integer -> Integer) -> IntHolder -> IntHolder liftInt f (IntHolder c) = IntHolder (f c) But I cannot generalise it to *Num:* data NumHolder = forall a. Num a => NumHolder a instance Show NumHolder where show (NumHolder n) = show n liftNum :: (Num a) => (a -> a) -> NumHolder -> NumHolder liftNum f (NumHolder c) = NumHolder (f c) The error message I get is the following: Couldn't match expected type `a' against inferred type `a1' `a' is a rigid type variable bound by the type signature for `liftNum' at Lifts.hs:54:16 `a1' is a rigid type variable bound by the constructor `NumHolder' at Lifts.hs:55:11 In the first argument of `f', namely `c' In the first argument of `NumHolder', namely `(f c)' In the expression: NumHolder (f c) Regards, -- Ozgur Akgun

3 3

haddock - error
by Andrew U. Frank 22 Jan '10

22 Jan '10

the problem with me getting no haddock output whatsoever was that i had not reconfigured cabal after replacing haddock 2.4 by 2.5 (by installing it with cabal). it would be helpful if there were an error message - but i can clearly see that this is difficult to achieve in this case. thanks for the help!

1 0

Re: Is Haskell capable of matching C in string processing performance?
by John Lato 22 Jan '10

22 Jan '10

> From: Heinrich Apfelmus <apfelmus(a)quantentunnel.de> > Don Stewart wrote: >> jmillikin: >>> Here's the fastest Haskell version I could come up with. It discards >>> all error handling, validation, and correctness in the name of >>> performance, but still can't get anywhere near C: >>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=16423 >> >> Thanks for posting the code. >> >> You're not using bytestrings?? >> >> They were invented to deal with the problem of [Char] being a poor >> structure for large scale string processing, and you should have no >> problem getting C-like string performance. >> >> http://www.cse.unsw.edu.au/~dons/papers/CSL06.html > > In my limited experience, ByteStrings are great for reading data, but > not that good for writing data that is being generated on the fly. For > writing, good old difference lists or the Builder monoid / Put monad > from Data.Binary seem to be best. > If find that this is particularly true if you don't know the length of data to write in advance because it involves lots of new allocations and copying. Using Builder/Put is definitely a better approach. Out of curiousity, has anyone ever tried implementing a LinkedListString in C to check what its performance would be? I expect it would be pretty poor compared to standard strings. Cheers, John

1 0