February 2009 - Haskell-Cafe

Re: [Haskell-cafe] Purely funcional LU decomposition
by Henning Thielemann 05 Feb '09

05 Feb '09

2 1

Re: [Haskell-cafe] Purely funcional LU decomposition
by Henning Thielemann 05 Feb '09

05 Feb '09

1 0

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