- Haskell-Cafe - Haskell.org

Question about takeMVar
by Maurício 29 Nov '07

29 Nov '07

Hi, 'takeMVar' documentation says "if there are multiple threads blocked in takeMVar, and the MVar becomes full, only one thread will be woken up." Since 'takeMVar' is a reading function, i.e., it doesn't change the value of the "variable", why waking up only one thread? If we wake multiple threads, there's no risk of one changing the value while the other is reading. Does that mean that all threads waiting for that MVar will get the same value, even if one of those threads change it's value just after reading? Thanks, Maurício

4 3

functional languages and the financial industry
by Galchin Vasili 29 Nov '07

29 Nov '07

Hello, I have a job search agent/bot filtering for Haskell in particular ... it is interesting that a number are in the financial realm ... Check out ORIX....not to mention Jane Street ... Kind regards, Vasya

1 0

ghc 6.8.1 bug?
by SevenThunders 29 Nov '07

29 Nov '07

The good news is that my code compiles without error and much faster under ghc 6.8.1. The bad news is that there appear to be subtle bugs that did not occur when I compiled things under 6.6.1. One issue is that my code is somewhat complex and links into a C library as well. The new behavior is that under certain conditions a certain matrix inner product produces undefined floats, that should not be there. If the code is executed inside any function it fails but if the same code is reexecuted at the ghci prompt it works. Here is the gist of the code that I'm running main = do ... lots of computations and let clauses -- get a submatrix viewMatbotk wstart nsua su 1 suw -- get another submatrix viewMatbotk 0 nsua arrstart npaths sua -- complex non conjugated inner product (multiply the two submatrices) mulCFtF mprint If this is executed either in ghci as main or from a Dos prompt I get a matrix filled with bad values including a few that look like -1.#IND+1.87514i If I recompile everything in ghc-6.6.1 it works like charm. I make sure that I have deleted all the .o and .hi files. There is a dll that contains a C library I link to via running dlltool.exe. If I print out all the function inputs to the function viewMatbotk and then call them interactively in ghc 6.8.1 and call mulCFtF interactively it works correctly. both viewMatbotk and mulCFtF are C routines pulled in from the external library. I am at a complete loss how to debug this or how to pin down what exactly has changed between 6.6.1 and 6.8.1 that breaks this code so badly. This type of error stinks of some kind of memory issue, e.g. corrupted pointers. Any suggestions would be appreciated. Unfortunately the code base is rather involved and potentially proprietary so I can't publish all of the details. -- View this message in context: http://www.nabble.com/ghc-6.8.1-bug--tf4810375.html#a13763341 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

6 12

Re: [Haskell-cafe] A tale of Project Euler
by Andrew Coppin 29 Nov '07

29 Nov '07

Michaeljohn Clement wrote: > Andrew Coppin wrote: > >> First, somebody else wrote this in C: >> >> int n = 2 , m , primesFound = 0; >> >> for( n=0;n < MAX_NUMBERS;n++ ) >> if( prime[n] ) >> { >> primesFound++; >> >> if( primesFound == 10001 ) >> cout << n << " is the 10001st prime." << endl; >> > > Um, I can't *believe* nobody else pointed this > out, but that isn't C, it's C++. > Really? How can you tell? Well anyway, the guy who wrote it said it's C. I suppose it was a simple oversight...

3 2

Re: suggestion: add a .ehs file type
by Alex Young 28 Nov '07

28 Nov '07

Alex Jacobson wrote: > My original point (refined) was that I'd like a file extension (.ehs) > that defaults to including all extensions that don't change the meaning > of a .hs program but that may cause a small subset of them not to > compile (e.g. ones that use forall as a type variable, foreign as a > function, or 'd' as the result value of a list comprehension) > > This does not seem like a major change, does not break any existing > code, and has the advantage of making it really obvious when people are > going beyond haskell98. > It'll break all sorts of things when .ehs has to get merged into .hs the next time this conversation comes around, unless it's guaranteed that all .hs processors will eventually be upgraded to cope with .ehs semantics. I don't think anyone's arguing for that... -- Alex > -Alex- > > Simon Marlow wrote: >> I see, all you're saying is you'd like the default to be different. >> >> (That's not the same as saying "Extensions that change syntax are >> effectively declared by the use of that syntax", which is what you >> said earlier, BTW.) >> >> Well, we could change the default. I don't think it's a great idea >> personally - I think we should default to compiling whatever is the >> most recent standard, i.e. Haskell 98. But you're arguing that the >> proportion of Haskell 98 code that would fail to compile is relatively >> small; that might well be true. This isn't a decision we could take >> lightly, though. >> >> Furthermore, it's only something we could change in 6.10, by which >> time it is likely that we'll have a clearer idea of what Haskell' is, >> so there might well be a -fhaskell-prime flag (or it might even be the >> default). >> >> Cheers, >> Simon >> >> Alex Jacobson wrote: >>> >>> Simon, I think we've been trying to be too clever... >>> >>> The simple question is: for a given extension, what is the risk of >>> leaving it turned on by default? >>> >>> Clearly we don't want extensions turned on that causes code to >>> compile but with a different meaning. We may not want extensions >>> turned on that cause most reasonable code not to compile. >>> >>> But I would say neither risk is significant in the case of most >>> extensions. To use your examples: >>> >>> * FFI doesn't not cause h98 code to compile to a different meaning. >>> The worst case is that code that uses 'foreign' as a function name >>> doesn't compile. That seems okay in that more code probably uses FFI >>> than uses foreign as a function name and the user can apply a >>> language pragma to turn it off if really desired. >>> >>> * Existential types won't cause h98 code to compile with a different >>> meaning. The worst case is that code that uses 'forall' as a type >>> variable won't compile. That seems ok.... >>> >>> * TemplateHaskell also not compatible with h98. The worst case is >>> the loss "[d|" in list comprehensions. >>> >>> * MagicHash: Does not appear in the ToC or the Index of the user's >>> guide so should probably be turned off. I have no idea what it does. >>> >>> Note, in all cases where the extension is turned on by default, there >>> should be a language pragma to turn it off. >>> >>> >>> -Alex- >>> >>> Simon Marlow wrote: >>>> Alex Jacobson wrote: >>>>> >>>>> Simon, from what I can tell, with GHC 6.8.1, use of foreign as a >>>>> function name or forall as a type variable or leaving out a space >>>>> in a list-comprehension doesn't "parse differently" when the >>>>> relevant extensions are enabled, it causes a parse error. >>>> > >>>>> Extensions allow the same code to parse but with different meanings >>>>> need to be declared explicitly. But, extensions that are obvious >>>>> from syntax should be allowed to be declared simply from the use of >>>>> that syntax. >>>> >>>> So for the first example I gave, >>>> >>>> f x y = x 3# y >>>> >>>> the "MagicHash" extension is one that you'd require to be explicitly >>>> declared, because the expression parses both with and without the >>>> extension. >>>> >>>> Now, Let's take the Template Haskell example: >>>> >>>> f x = [d|d<-xs] >>>> >>>> So this is valid Haskell 98, but invalid H98+TH. You would >>>> therefore like this example to parse unambiguously as H98, correct? >>>> But in order to do that, our parser would need arbitrary lookahead: >>>> it can't tell whether the expression is legal H98+TH until it gets >>>> to the '<-' in this case. Certainly it's possible to implement this >>>> using a backtracking parser, but Haskell is supposed to be parsable >>>> with a shift-reduce parser such as the one GHC uses. Or we could >>>> try parsing the whole module with various combinations of extensions >>>> turned on or off, but I'm sure you can see the problems with that. >>>> >>>> So basically the problem is that you need a parser that parses a >>>> strict superset of Haskell98 - and that's hard to achieve. >>>> >>>> Cheers, >>>> Simon >>>> >>>>> I am not taking a position here on the merits of any extensions. >>>>> >>>>> -Alex- >>>>> >>>>> >>>>> Simon Marlow wrote: >>>>>> Alex Jacobson wrote: >>>>>> >>>>>>> Extensions that change syntax are effectively declared by the use >>>>>>> of that syntax. If you can parse the source, then you know which >>>>>>> extensions it uses. >>>>>> >>>>>> I thought we'd already established that this isn't possible. Here >>>>>> are some code fragments that parse differently depending on which >>>>>> extensions are enabled: >>>>>> >>>>>> f x y = x 3# y >>>>>> >>>>>> f x = [d|d<-xs] >>>>>> >>>>>> foreign x = x >>>>>> >>>>>> f :: forall -> forall -> forall >>>>>> >>>>>> You could argue that these syntax extensions are therefore badly >>>>>> designed, but that's a separate discussion. >>>>>> >>>>>> Cheers, >>>>>> Simon >>>>>> >>>>>>> -Alex- >>>>>>> >>>>>>> >>>>>>> Duncan Coutts wrote: >>>>>>>> On Fri, 2007-11-23 at 16:26 +0100, Wolfgang Jeltsch wrote: >>>>>>>>> Am Freitag, 23. November 2007 03:37 schrieben Sie: >>>>>>>>>> On Fri, 2007-11-23 at 01:50 +0100, Wolfgang Jeltsch wrote: >>>>>>>>>>> Dont’t just think in terms of single modules. If I have a >>>>>>>>>>> Cabal package, >>>>>>>>>>> I can declare used extensions in the Cabal file. A user can >>>>>>>>>>> decide not >>>>>>>>>>> to start building at all if he/she sees that the package uses an >>>>>>>>>>> extension unsupported by the compiler. >>>>>>>>>> Indeed. In theory Cabal checks all the extensions declared to >>>>>>>>>> be used by >>>>>>>>>> the package are supported by the selected compiler. In >>>>>>>>>> practise I'm not >>>>>>>>>> sure how well it does this or what kind of error message we get. >>>>>>>> >>>>>>>>> The problem is, of course, that you are not forced to specify >>>>>>>>> all used extensions in the Cabal file since you can still use >>>>>>>>> language pragmas. Sometimes it is even desirable to use >>>>>>>>> LANGUAGE pragmas instead of information in the Cabal file. For >>>>>>>>> example, even if some modules use undecidable instances, I >>>>>>>>> might not want all modules of the package to be compiled with >>>>>>>>> -XUndecidableInstances since this could hide problems with my >>>>>>>>> class structure. >>>>>>>> >>>>>>>> Our tentative plan there is to separate the extensions field >>>>>>>> into those >>>>>>>> used in some module, and those applied by cabal to every module. >>>>>>>> So that >>>>>>>> would allow you to specify a feature in one file but not all, while >>>>>>>> still declaring to the outside world that the package uses the >>>>>>>> feature. >>>>>>>> >>>>>>>> As for enforcing that, that may come almost for free when we get >>>>>>>> dependency chasing as we'll be looking for imports anyway. It >>>>>>>> shouldn't >>>>>>>> be much harder to look for language pragmas too. >>>>>>>> >>>>>>>> Duncan >>>>>>>> _______________________________________________ >>>>>>>> Glasgow-haskell-users mailing list >>>>>>>> Glasgow-haskell-users(a)haskell.org >>>>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Glasgow-haskell-users mailing list >>>>>>> Glasgow-haskell-users(a)haskell.org >>>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>>>>> >>>>> >>>>> >>> >>> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 1

nbody (my own attempt) and performance problems
by Ryan Dickie 28 Nov '07

28 Nov '07

I thought it would be a nice exercise (and a good learning experience) to try and solve the nbody problem from the debian language shootout. Unfortunately, my code sucks. There is a massive space leak and performance is even worse. On the bright side, my implementation is purely functional. My twist: I manually unrolled a few loops from the C++ version. I believe that most of my performance problems stem from my abuse of tuple. The bodies are passed as a tuple of planets, a planet is a tuple of (position, velocity, mass) and the vectors position and velocity are also tuples of type double. My lame justification for that is to make it nice and handy to pass data around. Any tips would be greatly appreciated. --ryan

3 4

Downside of -fglasgow-extensions
by manu 28 Nov '07

28 Nov '07

Hello, I'm trying to build diverse packages from Hackage with ghc 6.8.1, they usually fail to build because of missing language extensions. Sometimes I am unable to determine the proper name of the extension missing in .cabal I tend to slap {- #OPTIONS -fglasgow-exts #-} at the top of the troublesome file. It works, but out of curiosity, what is the downside of such an approach ? (bigger executables ?) Thanks M

4 3

RFI: HDBC-1.1.3 build error
by Jim Stuttard 28 Nov '07

28 Nov '07

ubuntu gutsy ghc-6.8.1 HDBC-1.1.3$ runghc Setup.lhs build Preprocessing library HDBC-1.1.3... Building HDBC-1.1.3... [3 of 6] Compiling Database.HDBC.Types ( Database/HDBC/Types.hs, dist/build/Database/HDBC/Types.o ) Database/HDBC/Types.hs:208:0: Illegal polymorphic or qualified type: forall conn. (IConnection conn) => conn -> b In the type signature for `withWConn': withWConn :: forall b. ConnWrapper -> (forall conn. (IConnection conn) => conn -> b) -> b TIA

2 1

Why aren't Float and Double Bounded?
by Jason Dusek 28 Nov '07

28 Nov '07

Among numeric types, it seems that only integer types are Bounded. -- _jsn

9 12

A tale of Project Euler
by Andrew Coppin 28 Nov '07

28 Nov '07

Hi guys. Somebody just introduced me to a thing called "Project Euler". I gather it's well known around here... Anyway, I was a little bit concerned about problem #7. The problem is basically "figure out what the 10,001st prime number is". Consider the following two programs for solving this: First, somebody else wrote this in C: int n = 2 , m , primesFound = 0; for( n=0;n < MAX_NUMBERS;n++ ) if( prime[n] ) { primesFound++; if( primesFound == 10001 ) cout << n << " is the 10001st prime." << endl; for(m=2*n;m<MAX_NUMBERS;m+=n) prime[m]=false; } Second, my implementation in Haskell: primes :: [Integer] primes = seive [2..] where seive (p:xs) = p : seive (filter (\x -> x `mod` p > 0) xs) main = print (primes !! 10000) Well, we know who's winning the beauty contest. But here's the worrying thing: C program: 0.016 seconds Haskell program: 41 seconds Eeeps! o_O That's Not Good(tm). Replacing "primes :: [Integer]" with "primes :: [Word32]" speeds the Haskell version up to 18 seconds, which is much faster but still a joke compared to C. Running the Haskell code on a 2.2 GHz AMD Athlon64 X2 instead of a 1.5 GHz AMD Athlon drops the execution time down to 3 seconds. (So clearly the box I was using in my lunch break at work is *seriously* slow... presumably the PC running the C code isn't.) So, now I have a Haskell version that's "only" several hundred times slower. Neither program is especially optimised, yet the C version is drastically faster. This makes me sad. :-( By the way... I tried using Data.List.Stream instead. This made the program about 40% slower. I also tried both -fasm and -fvia-c. The difference was statistically insignificant. (Hey guys, nice work on the native codegen!) The difference in compilation speed was fairly drastic though, needless to say. (The machine is kinda low on RAM, so trying to call GCC makes it thrash like hell. So does linking, actually...) Also, I'm stuck with problem #10. (Find the sum of all primes less than 1 million.) I've let the program run for well over 15 minutes, and still no answer is forthcomming. It's implemented using the same primes function as above, with a simple filter and sum. (The type has to be changed to [Word64] to avoid overflowing the result though.) The other guy claims to have a C solution that takes 12 ms. There's a hell of a difference between 12 ms and over half an hour...(!) Clearly something is horribly wrong here. Uh... help?

8 14