- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Bytestrings vs String? parameters within package names?
by Henning Thielemann 05 Feb '09

05 Feb '09

1 0

Define variable types
by Tsunkiet Man 05 Feb '09

05 Feb '09

Hello, I'm new to Haskell and it seems like a very nice language to learn. However I'm not really familiar with the errormessages it produces. I am using a Helium interpreter. I've created the following module (however it is just a small sketch). I've written the following code: fac :: Int -> Int fac n = product[1..n] boven :: Int -> Int -> Int boven n k = (fac n) `div` fac k * fac (n-k) bin :: Int -> Int -> Int -> Int bin n k p |(n-k)>0 && k>0 = (boven n k) * (p^k) * (1-p)^(n-k) |(n-k)<0 && k>0 = (boven n k) * (p^k) * (1/((1-p)^(-(n-k)))) |(n-k)<0 && k<0 = (boven n k) * (1/(p^(-k))) * (1/((1-p)^(-(n-k)))) When I load this into my interpreter it says: Compiling ./Test.hs (11,55): Type error in infix application expression : 1 / ((1 - p) ^ (-(n - k))) operator : / type : Float -> Float -> Float does not match : Int -> Int -> Int (12,47): Type error in infix application expression : 1 / (p ^ (-k)) operator : / type : Float -> Float -> Float does not match : Int -> Int -> a (12,62): Type error in infix application expression : 1 / ((1 - p) ^ (-(n - k))) operator : / type : Float -> Float -> Float does not match : Int -> Int -> a Compilation failed with 3 errors Some details that might be usefull: Line 11 is |(n-k)<0 && k>0 = (boven n k) * (p^k) * (1/((1-p)^(-(n-k)))) Line 12 is |(n-k)<0 && k<0 = (boven n k) * (1/(p^(-k))) * (1/((1-p)^(-(n-k)))) So my question is: how can I fix these errors? (I used these lines of codes because it is not possible to use a negative exponent in the Helium interpreter.) Thank you for answering my question! Greetings JTKM

6 5

Crash using GHCi and GHC API under Windows
by Peter Verswyvelen 05 Feb '09

05 Feb '09

We have a program that uses the GHC API to dynamically compile and run new code. We're using GHC 6.10.1 Under GHCi it works fine under OSX, but when running it on Windows, I get Loading package ghc-prim ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol _hs_gtWord64 whilst processing object file C:\app\ghc-6.10.1\ghc-prim-0.1.0.0\HSghc-prim-0.1.0.0.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. When compiling the program using GHC --make, it runs fine Is this a know issue? Other people encountered this? Thanks, Peter

1 0

darcs send errors that I don't understand ....
by Galchin, Vasili 05 Feb '09

05 Feb '09

Shall I send this patch? (1/1) [ynWvpxqadjk], or ? for help: y Error in execvp: No such file or directory darcs: timer_settime: Invalid argument Failed to execute external command: /usr/sbin/sendmail -i -t Lowlevel error: execvp: Illegal seek Redirects: (File "/home/vigalchin/FTP/Ketil/biolib/darcsOuDSC9",Null,AsIs) Can anybody help me on the errors above? (The /usr/sbin/sendmail I think I understand ... probably haven't set up sendmail yet). Kind regards, Vasili

2 1

pure crisis :)
by Bulat Ziganshin 05 Feb '09

05 Feb '09

Hello haskell-cafe, pure functional denotation for crisis: (_|_) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

6 5

Open unqualified imports
by eyal.lotem＠gmail.com 05 Feb '09

05 Feb '09

Hi, I would like to suggest a change to Haskell prime's handling of imports. First, let me define a few terms: Qualified import: import qualified Data.Map [as Map] Closed-unqualified import: import Data.Map(Map, lookup) Open-unqualified import: import Data.Map I believe that the last type, open-unqualified is a really bad idea, and should be discouraged or even disallowed. It should definitely not be the default, like it is today. These are my reasons: A) Most importantly, reading code that has even a few open unqualified imports makes deciphering where names are coming from really difficult. The other two forms make it really easy. Code is read more often than it is written -- lets optimize for the reading case. B) Code that has open unqualified imports may break when new symbols are added to the libraries its importing. This means that libraries cannot even be considered backwards compatible if they retain semantics, but add new exported names. C) In my experience, Haskell modules can map their semantics to standard type-classes such as Monoid, Functor, Applicative, etc. This means that many Haskell modules can do without exporting many names. Sometimes, they can export no names at all (Only instances). This means that closed-unqualified imports often do just fine. When there are many exported names, qualified imports are good. ----------------- I think currently many modules are designed to be imported unqualified, and this is unfortunate. Haskell' libraries can fix this. For example, the various Monadic counterparts such as mapM, replicateM, etc could do without the "M" in their names, and one could use: import qualified Control.Monad as M M.for M.map and so on. Additionally, I think there are some strong sentiments against the choice of the function-composition dot as the qualified module name lookup symbol. It discourages people from using qualified imports. Some other symbol ought to be used, but its not clear which symbol is free. Perhaps if unicode operators are allowed, then function composition can move to the "right" symbol. I believe qualified imports should probably have this syntax: import Control.Monad as M Closed-qualified imports can remain in the same syntax. Open-qualified imports should probably be discouraged with a syntax like: import unqualified Control.Monad And symbol clashes with these should probably just always choose the overriding name. Additionally, it would be nice if open unqualified imported were considered quick&dirty enough for -Wall to warn that they generate name clashes or are more difficult to read, to further discourage them. Eyal

8 9

Temporarily overriding Data.Generics
by Deniz Dogan 04 Feb '09

04 Feb '09

Hi I'm currently working on "hacking" Data.Generics for my master thesis. I'm basically trying to find out whether it can be made a bit faster using e.g. rewrite rules. The problem I'm having is that I need an easy way to import my own modified version of Data.Generics (currently located in the same directory as my testing program) without unregistering or hiding syb-0.1.0.0 as base seems to depend on it. I've read the GHC user manual trying to find nice ways to do this using a bunch of different parameters to ghc, but I can't figure it out. Does anyone here know? Any help appreciated, Deniz

2 1

Elegant & powerful replacement for CSS
by Conal Elliott 04 Feb '09

04 Feb '09

[Spin-off from the haskell-cafe discussion on functional/denotational GUI toolkits] I've been wondering for a while now what a well-designed alternative to CSS could be, where well-designed would mean consistent, composable, orthogonal, functional, based on an elegantly compelling semantic model (denotational). - Conal

11 15

Data Parallel Haskell Question
by James Swaine 04 Feb '09

04 Feb '09

I am somewhat of a beginner with DPH and wanted to ask a few (maybe elementary) questions. There appear to be two main libraries - regular and unlifted. I was a little unclear on the difference between the two and was hoping to get some clarification. If you use the 'regular' api, it seems that you can use the sort of 'syntactic sugar' language extensions (e.g. [: blah blah :]), but you are restricted to the somewhat limited Prelude explicitly written for use with code that is to be vectorised. If you use the 'unlifted' libraries, are you able to use functions/types from the standard Prelude? My problem is that I want to write a recursively-subdividing radix sort (for integer keys), where on each iteration I partition my keys into separate sets based on whether a certain bit is set or not. So I start with the most significant digit bit (say 31), and then work down to the least significant digit. I can write this in DPH just fine, but I'm getting 'panic' errors when I attempt to compile, and I wonder if it has something to do with the fact that I'm using the standard Data.Bits to inspect bits of each key. {-# LANGUAGE PArr, ParallelListComp #-} {-# OPTIONS -fvectorise #-} module RankPar(radix_sort) where import qualified Prelude import Data.Array.Parallel.PArray (fromList) import Data.Array.Parallel.Prelude ((+:+), fromPArrayP, not) import Data.Array.Parallel.Prelude.Int import Data.Bits {-# NOINLINE radix_sort #-} radix_sort :: Int -> [:Int:] -> [:Int:] radix_sort (-1) keys = keys radix_sort bit [:k:] = [:k:] radix_sort bit [: :] = [: :] radix_sort bit keys = (radix_sort (bit - 1) left) +:+ (radix_sort (bit - 1) right) where right = [: x | x <- keys, (testBit x bit) :] left = [: y | y <- keys, (not (testBit y bit)) :] Syntactically, this looks correct to me, but won't compile. Any ideas? Thanks all! -James

1 0

ANN: UrlDisp, a friendly URL dispatching library
by Artyom Shalkhakov 04 Feb '09

04 Feb '09

Hello, I would like to announce the first release of UrlDisp. <http://hackage.haskell.org/cgi-bin/hackage-scripts/package/UrlDisp> It's a small library for URL dispatching (aka routing). Right now it works with CGI, and should be compatible with FastCGI as well (not tested). Happstack compatibility is planned. Documentation and usage examples are available at HaskellWiki: <http://www.haskell.org/haskellwiki/UrlDisp> Thanks to Sterling Clover for his HVAC; this is where inspiration came from. Cheers, Artyom Shalkhakov.

1 0