- Haskell-Cafe - Haskell.org

Parsec and (then?) type-check
by Greg Fitzgerald 13 Dec '08

13 Dec '08

Parser gurus, When you write a parser with a library like Parsec, do you typically type-check while parsing, or afterward in a separate pass? The latter is more modular, but it means labeling every element in the AST with the parser position so that you can give good error messages. Do you find the added modularity worth the hassle or just pack type-checking into the parser pass? Thanks, Greg

2 1

Memoization-question
by Mattias Bengtsson 12 Dec '08

12 Dec '08

The program below computes (f 27) almost instantly but if i replace the definition of (f n) below with (f n = f (n - 1) * f (n -1)) then it takes around 12s to terminate. I realize this is because the original version caches results and only has to calculate, for example, (f 25) once instead of (i guess) four times. There is probably a good reason why this isn't caught by the compiler. But I'm interested in why. Anyone care to explain? > main = print (f 27) > > f 0 = 1 > f n = let f' = f (n-1) > in f' * f' (compiled with ghc --make -O2) Mattias

5 8

Data.Array.Storable vs GC
by David F. Place 12 Dec '08

12 Dec '08

If you have a giant unboxed array that will never become garbage, it would be nice to put it somewhere where the GC won't bother with it. Since Data.Array.Storable arrays are allocated in the C heap, I thought it would be a good choice. However, I am getting very poor performance due to the GC copying 6G in each run. The only explanation that I can think of is that it is copying my giant array. Am I wrong in my understanding that Data.Array.Storable arrays should not be copied by the GC? BTW, I am using GHC 6.10.1 on linux. Thanks for reading.

4 6

Multi-parameter Type Class
by Paul Keir 12 Dec '08

12 Dec '08

Hi all, I've been trying to refactor my tree conversion code to make better use of type classes; and I've discovered multi-parameter type classes and functional dependencies. I have a class with a function a2b, and I'd like "map" to be used when it's a list of type a. I've created a simple failing example: data Foo = Foo Bar deriving(Show) data Bar = Bar String deriving(Show) class ZOT a b | a -> b where zot :: a -> b instance ZOT Foo Integer where zot x = 17 instance ZOT Bar String where zot x = "Eighteen" instance ZOT [x] [y] where -- This bit zot xs = map zot xs -- fails main = do print $ zot $ Foo $ Bar "Blah" print $ zot $ Bar "Blah" print $ zot $ [Bar "Blah", Bar "Blah"] -- No map here please I know this would work if the third instance of zot explicitly took [Bar] and [String]. Can I not instead generalise for all the ADTs in my tree in the way I've outlined? Must I instantiate for the type of each list pair? Cheers, Paul

5 6

Re: problems with hs-plugins load-eval (possible bug)
by Alberto G. Corona 12 Dec '08

12 Dec '08

The duplicate definition error appears when I compile Main.hs and execute it. But when I run it with runghc the behaviour is different. It works well: > runghc Main.hs 3 Any idea? is this a bug of hs-plugins? it is just something expected?? 2008/12/6 Alberto G. Corona <agocorona(a)gmail.com> > I have a web server which load server extensions. these extensions > eval-uate configuration files that contains code (user-editable workflow > descriptions). The problem is that I need common definitions (inside > imported modules) for the extensions and for the configuration files. This > is not permitted by ha-plugins. > > The minimal code example are the files below. main loads eval.hs , that > evaluate a expression. The common definitions are in Include.hs. The error > is: > > *GHCi runtime linker: fatal error: I found a duplicate definition for > symbol > Include_sum1_srt > whilst processing object file > /home/magocoal/haskell/devel/votesWorkflow/src/unused/tests/Include.o > > This could be caused by: > * Loading two different object files which export the same symbol > * Specifying the same object file twice on the GHCi command line > * An incorrect `package.conf' entry, causing some object to be > loaded twice. > GHCi cannot safely continue in this situation. Exiting now. Sorry. > * > > > ** > Do you kno how to solve the problem while maintaining the functionality? > > -------Include.hs------- > module Include where > > sum [x,y]= x+y > > > ------Main.hs----- > module Main > where > > import Include > import System.Plugins > > main= do > s <-loadExec "eval.o" "mainc" > print s > > loadExec:: String-> String->IO String > loadExec file method = do > > mv <- load file ["."] [] method > case mv of > LoadSuccess mod v -> v :: IO String > LoadFailure msg -> return $ concat msg > > > > ------------Eval.hs-------- > > module Eval(mainc) where > import System.IO.Unsafe > import System.Eval.Haskell > > mainc= do i <- unsafeEval_ "sum1 [1,2]" ["Include"] [] []["."] :: IO > (Either [String] Int) > return $ show i > > > > >

2 2

Haskell project proposals reddit
by Don Stewart 11 Dec '08

11 Dec '08

I'd like to echo Jason's remarks earlier. http://www.reddit.com/r/haskell_proposals/ We've tried for a couple of years now to efficiently track 'wanted libraries' for the community, but never with much success. In particular, two approaches have been tried: * a wiki page * the 200{6,7,8} summer of code trac neither proved workable long term, likely because no one knew about them, they're harder to contribute to and other factors. Now I know there's a lot of spare Haskell capacity in this community. 3000 mailing list readers, but only 70 new libraries a week being uploaded to Hackage --- that's not how we take over the world! So this is your chance to contribute: * propose new libraries, and explain why you'd want them * vote on things you'd like to see * pick up tasks that sound interesting Let's try to make this work! -- Don

9 10

unsafeThawByteArray#
by Patrick Perry 11 Dec '08

11 Dec '08

I've noticed that there is no longer an "unsafeThawByteArray#" function in GHC.Prim. Looking through the darcs history, I found a patch with description: [project @ 2000-03-13 12:11:43 by simonmar] simonmar**20000313121144 Remove unsafeThawByteArray# primop (which was a no-op), and use unsafeCoerce# instead. ] Is the following code safe? data IntArray = IntArray !Int (ByteArray#) data STIntArray s = STIntArray !Int (MutableByteArray# s) unsafeThaw :: IntArray -> ST s (STIntArray s) unsafeThaw (IntArray n arr#) = ST $ \s1# -> let coerceArray :: State# s -> MutableByteArray# s coerceArray _ = unsafeCoerce# arr# marr# = coerceArray s1# marr = STIntArray n marr# in (# s1#, marr #) Thanks, Patrick

1 0

Re: [Haskell-cafe] A curios monad
by Andrew Coppin 11 Dec '08

11 Dec '08

Alberto G. Corona wrote: > but because keys and data must be of the same type, you are restricted > to instances of Eq and Ord. Itsn´n true? > > 2008/12/11 Andrew Coppin <andrewcoppin(a)btinternet.com > <mailto:andrewcoppin@btinternet.com>> > > Alberto G. Corona wrote: > > Well, you have not to use typeable, but instead you need to > use instances of Eq and Ord. This is because the values and > the keys must be of the same type. this is the tradeoff. > > > Not really, no. The *keys* need Eq and Ord, but the values I'm > storing don't. The values I'm storing don't need any specific > properties at all. That's what I like about it. > > No. Keys are of type "Key v", where "v" can be anything. It's a phantom type, so it's not used for anything (except knowing what to coerce the value back to when it's looked up). "Key v" is just an alias to Int, which *is* in Eq and Ord, as required. There are no constraints on "v" at all.

1 0

problems configuring hs-plugins 1.3.1 in windows
by Alberto G. Corona 11 Dec '08

11 Dec '08

I have problems compiling plugins 1.3.1 in windows at the configure phase configure: error C compiler cannot create executables I use ghc 6.8.2 I know that plugins is nor much tested under windows but I´m trying anyway. I think that this problem is very common also in Linux. I tried to find references to this error ut all of then are old (for plugins 1.2) and it is supposed to be solved. Do you have any workaround? By the way the reported compiler used is gcc Responder Responder a todos Reenviar

1 0

Re: [Haskell-cafe] A curios monad
by Andrew Coppin 11 Dec '08

11 Dec '08

Alberto G. Corona wrote: > it is safe to use unsafeCoherce in your context? I mean, I think you > need to use instances of Data.Typeable (or some with the same > functionality) to make it safe. Like in Data.Dynamic... The *only* way for you to generate a Key value is to use the function I provide - which conviniently tags it with the type of value it's supposed to retreive. That means the type cast is guaranteed to cast it back to the type it was in the first place. ...unless you can muddle keys from other state threads up. In that case, all bets are off. I looked at using Data.Dynamic, but that only works for a few types. I wanted something that will work for *any* type.

1 0