February 2010 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

Easily generating efficient instances for classes
by Christian Höner zu Siederdissen 28 Feb '10

28 Feb '10

Hi, I am thinking about how to easily generate instances for a class. Each instance is a tuple with 1 or more elements. In addition there is a second tuple with the same number of elements but different type. This means getting longer and longer chains of something like (...,x3*x2,x2,0). - template haskell? - CPP and macros? Consider arrays with fast access like Data.Vector, but with higher dimensionality. Basically, I want (!) to fuse when used in Data.Vector code. A code abstract follows -- I will put this on hackage if there is insterest. And please comment if you think of something how to improve here. Viele Gruesse, Christian -- | Primitive multidimensional tables without bounds-checking. Internally, we -- used unboxed vectors. Construction expects the highest possible index in -- each dimension, not the length (which is highest index +1). This choice -- allows for easier construction using bounded types. Consider: "fromList True -- False [] :: PrimTable Bool Bool" which creates a 2-element table. -- | Fast lookup table: `a` encodes the storage index type, while (!) only -- requires that the index value is (Enum). data PrimTable a b = PrimTable {-# UNPACK #-} !a -- ^ the highest indices (every index starts at 0 (or 0,0 ...)) {-# UNPACK #-} !a -- ^ precalculated multiplication values {-# UNPACK #-} !(V.Vector b) -- ^ storage space -- | mutable fast lookup table data MPrimTable s a b = MPrimTable {-# UNPACK #-} !a {-# UNPACK #-} !a {-# UNPACK #-} !(V.MVector s b) class (V.Unbox b) => PrimTableOperations a b e where -- | Fast index operation using precomputed multiplication data. Does -- bounds-checking only using assert. (!) :: PrimTable a b -> e -> b {-# INLINE (!) #-} new :: (PrimMonad s) => e -> s (MPrimTable (PrimState s) a b) {-# INLINE new #-} newWith :: (PrimMonad s) => e -> b -> s (MPrimTable (PrimState s) a b) {-# INLINE newWith #-} read :: (PrimMonad s) => MPrimTable (PrimState s) a b -> e -> s b {-# INLINE read #-} write :: (PrimMonad s) => MPrimTable (PrimState s) a b -> e -> b -> s () {-# INLINE write #-} fromList :: e -> b -> [(e,b)] -> PrimTable a b fromList dim init xs = runST $ do mpt <- newWith dim init mapM_ (\(k,v) -> write mpt k v) xs unsafeFreeze mpt {-# INLINE fromList #-} -- | Two-dimensional tables. instance (Enum e, V.Unbox b) => PrimTableOperations (Int,Int) b (e,e) where (PrimTable (z2,z1) (n2,n1) arr) ! (k2,k1) = arr `V.unsafeIndex` (fromEnum k2 * n2 + fromEnum k1) {-# INLINE (!) #-} new (z2',z1') = do let z2 = fromEnum z2' +1 let z1 = fromEnum z1' +1 marr <- M.new $ z2 * z1 return $ MPrimTable (z2,z1) (z1,0) marr newWith (z2,z1) v = do mpt <- new (z2,z1) mapM_ (\k -> write mpt k v) [(k2,k1) | k2 <- [toEnum 0..z2], k1 <- [toEnum 0..z1]] return mpt read (MPrimTable (z2,z1) (n2,_) marr) (k2,k1) = M.read marr (fromEnum k2 * n2 + fromEnum k1) write (MPrimTable (z2,z1) (n2,_) marr) (k2,k1) v = M.write marr (fromEnum k2 * n2 + fromEnum k1) v -- example jarr :: PrimTable (Int,Int) Double jarr = fromList (2 :: Int,2 :: Int) 0.0 [((0,0),1.0),((0,1),2.0),((1,0),3.0),((1,1),4.0)] runj = [jarr ! (k :: (Int,Int)) | k <- [(0,0),(0,1),(1,0),(1,1)]]

3 2

Some great results on fused code with the LLVM backend
by Don Stewart 26 Feb '10

26 Feb '10

I tried out some of the vector and uvector fusion benchmarks with the new LLVM backend http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghc… and got some great results for the tight loops generated through fusion. Up to 2x faster than gcc -O3 in some cases. The LLVM backend looks very promising -- considering we've not even begun to explore the optimization pipeline at the level. -- Don

3 2

save-the-world or serializable continuations
by Ben 25 Feb '10

25 Feb '10

hello -- i'm wondering if there is any support for a common-lisp style "save-the-world" function in GHC, or more generally serializable continuations (in the Continuation monad?) And if not, what would it take to have it? It would be very useful for long-running restartable computations, amongst other things. I realize it is a very tricky thing to do right, but even simplified approximations would be great. best, ben

2 1

FW: Installing syb(-0.1.03) package in head version of Haskell
by Simon Peyton-Jones 24 Feb '10

24 Feb '10

Friends Can anyone help Kathleen out? She has a cabal-install issue. I think she's on a Mac. Many thanks Simon From: Kathleen Fisher [mailto:kathleen.fisher@gmail.com] Sent: 16 February 2010 22:54 To: Simon Peyton-Jones Subject: Fwd: Installing syb(-0.1.03) package in head version of Haskell Hi Simon, I'm trying to get the PADS file we were working on compiling under the HEAD version of Haskell, but I'm having trouble getting the Data.Generics module to install. I sent the question below to the libraries(a)haskell.org<mailto:libraries@haskell.org> last week, but I haven't seen any replies. Is that the right address? Or is there a different place to ask such questions? Thanks for any pointers! Kathleen Begin forwarded message: From: Kathleen Fisher <kathleen.fisher(a)gmail.com<mailto:kathleen.fisher@gmail.com>> Date: February 11, 2010 2:28:20 PM PST To: libraries(a)haskell.org<mailto:libraries@haskell.org> Subject: Installing syb(-0.1.03) package in head version of Haskell Hi all, I'm trying to get a program that uses the Data.Generics module to compile under the head version of GHC, but I am having trouble getting the syb package installed. I believe I am using the most recent version of cabal: kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/.cabal/bin/cabal --version cabal-install version 0.8.0 using version 1.8.0.1 of the Cabal library When I ask cabal to install the syb package, I get the following error: kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/.cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc Resolving dependencies... Downloading mtl-1.1.0.2... Configuring mtl-1.1.0.2... Preprocessing library mtl-1.1.0.2... ... Registering syb-0.1.0.3... cabal: ghc-pkg: <stdin>: hGetContents: invalid argument (invalid UTF-8 byte sequence) cabal: Error: some packages failed to install: language-c-quote-0.1 depends on syb-0.1.0.3 which failed to install. syb-0.1.0.3 failed during the building phase. The exception was: exit: ExitFailure 1 The full trace is included below. Here's the version information for the ghc I am running. Kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/sw/ghc-head/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 6.13.20100210 The cabal website suggests sending questions to this list... Any suggestions for how to fix this problem? Kathleen kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/.cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc Resolving dependencies... Downloading mtl-1.1.0.2... Configuring mtl-1.1.0.2... Preprocessing library mtl-1.1.0.2... Building mtl-1.1.0.2... ...stuff deleted... src/Data/Generics.hs:40:1: Warning: The import of `Prelude' is redundant except perhaps to import instances from `Prelude' To import instances alone, use: import Prelude() Registering syb-0.1.0.3... cabal: ghc-pkg: <stdin>: hGetContents: invalid argument (invalid UTF-8 byte sequence) cabal: Error: some packages failed to install: language-c-quote-0.1 depends on syb-0.1.0.3 which failed to install. syb-0.1.0.3 failed during the building phase. The exception was: exit: ExitFailure 1

8 16

create a DLL when using Gtk2hs
by Paqui Lucio 24 Feb '10

24 Feb '10

Hi, I am trying to generate a DLL for a Haskell program that imports Graphics.UI.Gtk from the Gtk2hs package. I have try to use the files .o that are in the Gtk2hs folder created by the package installer, but it does not work. Does somebody knows, how to generate a DLL when this package is used? Thanks in advance, Paqui --------------------------------- Paqui Lucio Dpto de LSI Facultad de Informática Paseo Manuel de Lardizabal, 1 20080-San Sebastián SPAIN --------------------------------- e-mail: paqui.lucio(a)ehu.es Tfn: (+34) (9)43 015049 Fax: (+34) (9)43 015590 Web: http://www.sc.ehu.es/paqui ---------------------------------

1 0

GHC FFI stub files
by Tyson Whitehead 23 Feb '10

23 Feb '10

I'm writing a perl module that interfaces some haskell code and its a bit of a pain because both perl and ghc have their own custom build system. Is there a way to get ghc to give you the gcc/as/ld options (library paths, include paths, flags, etc) required for the FFI stub files it generates? The best I've come up with so far is to extract them from GHC by telling it to use a "capture the arguments" command as the compiler and linker. Thanks! -Tyson (I could also tell the perl build system that ghc is c compiler, assembler, and linker, but then I need to do a bunch of wrapping with -optc and friends)

2 1

Shared GHC libraries and the runtime system
by Tyson Whitehead 23 Feb '10

23 Feb '10

I was working on a shared library that loads up the GHC runtime (via hs_init) and have been running into a bunch of undefined stg symbols. A bit of digging and it seems that GHC doesn't embed - the dependency libHSrts-ghc6.12.1.so, and - the associated rpath /usr/lib/ghc-6.12.1 into shared libraries that it builds. Thus, if your main executable isn't GHC generated (and hence has these), you run into unresolved symbols. I can work around this by manually adding them myself. Is there any reason GHC can't put this information by default into shared libraries though? Thanks! -Tyson PS: Further digging into the various shared libraries packaged with GHC (Debian GHC package 6.12.1-2) reveal that they are actually missing - the dependency libHSrts-ghc6.12.1.so, and - all rpaths (i.e., there are absolutely no rpaths in any of them) $ objdump -p /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.1.so ... Dynamic Section: NEEDED libHSinteger-gmp-0.2.0.0-ghc6.12.1.so NEEDED libgmp.so.3 NEEDED libHSghc-prim-0.2.0.0-ghc6.12.1.so NEEDED libc.so.6 SONAME libHSbase-4.2.0.0-ghc6.12.1.so ...

4 4

integer-simple by default
by Greg Fitzgerald 23 Feb '10

23 Feb '10

Static linking to GMP on Windows is sending me towards a bunch of red tape at work. What can I do to make integer-simple the default integer library for GHC? Need anything more than test suite and performance metrics? Any date planned for the 6.12.2 release? Thanks, Greg

8 15

Re: Quasi quoting
by Dave Bayer 22 Feb '10

22 Feb '10

Perhaps I missed this or I'm missing something, but seeing a mention of quasiquoting on another thread, I reread this entire thread just now before posting. If by "stealing syntax" we mean that the odd programmer who writes illegiblelinenoisewithoutspaceshastoaddtheoddspacehereandthere, then fine, sorry about the long post which you may freely ignore. What I read when I see "stealing syntax" is that a proposal makes some prior code impossible to write. Please clarify. I have no trouble distinguishing visually between the following forms [hex| 1.fffffp+1023 |] [ hex | hex <- [ 0..8 ] ] for two different reasons: [1] I'd never leave out the spaces for the list comprehension, while I'd always leave out the spaces for quasiquoting. [2] It's completely obvious to a human reader that the first form can't be a list comprehension, because of the trailing |] which would be a parse error. Let's recall that indentation-based parsing like we use in Haskell, Python was once radical, and still jars some people. Spaces are already significant for everyone, this just leans on them a bit more. A Lisp programmer would have no issues distinguishing these forms, because [hex| is a single token for the Lisp programmer. A freshman parser for quasiquoting would get this right by accident, failing to catch the quasiquoting that used spaces, falling correctly through to the list comprehension. More generally, humans always resolve ambiguity by parsing several ways in parallel, and accepting the highest priority parse that succeeds. I always expect computer languages to work this way, and my heart is always broken. Why can't Haskell evolve in this direction, as proposals like this increase its code density? Reading "Coders at Work", all of my coding zombie masters abandoned Lisp (as I did) because code density is a Good Thing. It's a mild nuisance to wait on the closing |] to decide, but only a mild nuisance. This reminds me of heredocs, where a traditional (e.g. Perl) heredoc help prog = <<“EOF” Usage: “prog” input output “prog” -h original input output EOF looks like it's stealing syntax, but there is utterly no issue at all, if one waits till the end to resolve the ambiguity, giving priority to a correct heredoc. (I need to wait till the end in any case to steal the indent.) Somehow this was never accepted as a reasonable idea in the heredoc thread either, yet I took this from working code that my custom literate preprocessor handles without incident. So what am I missing? Require no spaces to open quasiquoting, and/or require |] to close quasiquoting, falling through to whatever else Haskell will accept if these conditions aren't met? Then it remains possible to code any list comprehension. On Jan 31, 2010, at 10:50 PM, Simon Peyton-Jones wrote: > So the proposed change will make things *more* uniform, by grabbing every > "[blah|" as lexeme. On Feb 1, 2010, at 1:43 AM, Malcolm Wallace wrote: > I am not myself a TH or QQ user, but it has always bothered me slightly that the syntax for them steals some valid list comprehensions. On Feb 22, 2010, at 5:15 AM, Simon Peyton-Jones wrote: > Or, alternatively, use quasiquoting > > [hex| 1.fffffp+1023 |]

1 0