- Haskell-Cafe - Haskell.org

Compatible problem with GHC 6.10.1
by Andy Stewart 03 Dec '08

03 Dec '08

Hi all, I use Debian and GHC 6.8.2-7 Have install cabal, xmonad, gtk2hs with GHC 6.8.2-7 But when upgrade to GHC 6.10.1, i failed to install XMonad 0.8 and gtk2hs 0.9.13 I heard someone install success with develop version. So anyone success install XMonad and gtk2hs with GHC 6.10.1? BTW, i want to know the details compatible problem between 6.8 with 6.10? Is most libraries have compatible with GHC 6.10.1? Any suggestions? Thanks. -- Andy

5 14

The Knight's Tour: solutions please
by Don Stewart 03 Dec '08

03 Dec '08

Lee Pike forwarded the following: "Solving the Knight's Tour Puzzle In 60 Lines of Python" http://developers.slashdot.org/article.pl?sid=08/11/30/1722203 Seems that perhaps (someone expert in) Haskell could do even better? Maybe even parallelize the problem? :) So, team, anyone want to implement a Knight's Tour solver in a list monad/list comprehension one liner? These little puzzles are made for fast languages with backtracking monads.... Post solutions to the wiki.. -- Don

5 9

Moving the messages for compiler to another file?
by nml 02 Dec '08

02 Dec '08

How about moving the messages for compiler to an additional file? My motivation is that we often face a trade-off between aesthetical(elegant code) and practical(efficient code). Like pragmas and strictness annotations, I often feel they make the source code ugly. They don't affect the semantics of our programs, do they? Some people would say this beautifying should be accomplished by an editor, like hiding/showing option for those information. But such separation has additional benefits. For instance, making the source code more compiler-independent. (yeah, this is not the case with language-extensions) And we avoid dispersing those information among our lines. (or even files) In some cases, it would be convenient. I'm not sure if this idea is reasonable, reachable or just naive. Suggestions? Best regards -nml

2 1

GHC 6.10 and OpenGL
by Paul L 02 Dec '08

02 Dec '08

Hi everyone, It's sad to see the OpenGL binding being dropped from GHC binary installers starting from 6.10. Though this issue has been brought up and discussed before, I'm sure a lot of people who based their work on OpenGL would share the same sympathy. I'm not here to argue whether this decision by GHC dev team is right or wrong, but what's really causing the pain is that the OpenGL binding doesn't have its own binary installer for Windows, and compilation from source on this platform is non-trivial. I wouldn't recommend doing it for ordinary users. So my question is, are we going to see a binary installer for OpenGL binding provided separately from either HOpenGL site, or Hackage? Or even the GHC installation page? -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale

10 22

global variables for foreign C functions
by Andrea Rossato 02 Dec '08

02 Dec '08

Hello, I'm writing the bindings to a C library which uses, in some functions, global variables. To make it clearer, those functions need a global variable to be defined. A C program using my_function, one of the library functions, would look like: char progname[] = "a_program_name"; int main( int argc, char *argv[] ) { param p; my_function ( &p ) etc. I've been searching the ML, the wiki, the net, etc. without finding some examples on how such things are dealt with in Haskell - is it possible, BTW? If I import those functions without defining the global variable I get a linker error: /usr/lib/mylib.a(cfile.o): In function `my_function': cfile.c:(.text+0x510): undefined reference to `progname' I hope the issue is clear. Any help would be greatly appreciated. Andrea

5 5

The Knight's Tour: solutions please
by oleg＠okmij.org 02 Dec '08

02 Dec '08

Yes, there is a solution for n=99 and for n=100 for that matter -- which can be found under one second. I only had to make a trivial modification to the previously posted code > tour n k s b | k > n*n = return b > | otherwise = do next <- (foldr mplus mzero).map return $ successors n b s > tour n (k+1) next $ insrt next k b I replaced foldl1 mplus with foldr mplus zero. Here are the results: for n=99, the first line of the board is 1 4 2885 214 309 6 311 216 307 8 315 218 305 10 319 220 303 12 2021 222 301 14 1727 224 299 16 1699 226 297 18 1561 228 295 20 1247 230 293 22 1227 232 291 24 1165 234 289 26 1007 236 287 28 965 238 285 30 775 240 283 32 759 242 281 34 625 244 279 36 559 246 277 38 543 248 275 40 455 250 273 42 435 252 271 44 407 254 269 46 377 256 267 48 365 258 65 50 63 60 67 52 55 time is 0m0.730s n=100 1 4 205 9996 209 6 207 9940 211 8 9897 9900 213 10 9895 9906 215 12 9809 9880 217 14 9807 9740 219 16 9799 9072 221 18 8445 8864 223 20 8443 8378 225 22 8347 8352 227 24 8331 7860 229 26 7863 7844 231 28 7749 7754 233 30 7735 7742 235 32 7733 7320 237 34 677 640 239 36 597 568 241 38 535 540 243 40 517 500 245 42 473 452 247 44 371 358 249 46 305 310 251 48 293 286 253 50 291 270 255 52 259 262 time is 0m0.373s For n=101, time is 0m0.388s wren ng thornton wrote: > FWIW, fair choice (interleave) is much slower than unfair choice (mplus) > in logict. Unfortunately this means you need to know a lot about the > problem domain to correctly choose between them when maximal performance > is at stake; just using fair choice everywhere costs too much for many > problems. I believe that FBackTrack relieves one from making the above choice: the ordinary mplus is FBackTrack is both fair and speedy. There is no longer any need for interleave; btw, interleave does not ensure completeness, whereas FBackTrack, I conjecture, implements a complete search procedure: if there is a solution, FBackTrack will eventually find one. The only `drawback' of using FBackTrack is that the order of the answers (if there are several) is essentially unpredictable. Informally, the answers are delivered in the order of the difficulty of finding them. This drawback is relative however: if we insist that the sequence of answers of (m1 `mplus` m2) is the concatenation of the sequences of answers of m1 and then m2, our search procedure is incomplete.

3 2

Sugestion for a basic Utf8 type.
by Mauricio 02 Dec '08

02 Dec '08

Hi, I would like to sugest a new basic type in Haskell. What if we had something like this (with any other quoting character): «Je ne parle pas français. Meu nome é Maurício. ¿Hablas español?» This would be of type Utf8. I think now it is not a bad idea, since Haskell source code is supposed to be utf-8. The internal representation of this datatype would be a null terminated utf-8 byte vector. No standard operations would be defined on that type, i.e., it would be a “communication standard” between everybody, but module writers could develop different basic usage based on operations on them using Foreign. (I think it would be dificult to set default operations, since there are so many things you can do with utf-8.) Pros: * There would be no doubt you can use utf-8 when using this, since there's no conversion involved. * Cleaner code on utf8 operations, maybe. There are many utf8 modules today with different goals in mind, I thing it would be nice if they could share this common basic type and a common underline implementation. Cons: * Probably, many. I have no deep understanding of Haskell. Thanks for your attention, Maurício

3 5

import
by Galchin, Vasili 02 Dec '08

02 Dec '08

Hello, I am a little uncertain about "import" semantics in a hierarchical package ... i.e. if I import the root of a package root do I get everything under the "root's" namespace, i.e. the namespace tree? thanks, vasili

3 4

ANNOUNCE: Haskell Communities and Activities Report (15th ed., November 2008)
by Janis Voigtlaender 02 Dec '08

02 Dec '08

On behalf of the many, many contributors, I am pleased to announce that the Haskell Communities and Activities Report (15th edition, November 2008) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in PDF and HTML formats. Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as I did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline ;-) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When I try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ---------------------------------------- End of April 2009: target deadline for contributions to the May 2009 edition of the HC&A Report ---------------------------------------- Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to "register" with the editor for a simple e-mail reminder in April (you could point me to them as well, and I can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Janis Voigtlaender <hcar at haskell.org> -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

3 2

What causes <<loop>>?
by Martin Hofmann 02 Dec '08

02 Dec '08

I am picking up a discussion with the same topic from haskell-users on 8th November. Thunks with reference on themselves was mentioned as main reason for <<loop>>. > A safe recursive definition would be > let x = Foo (x+1) > However, if you leave out the constructor, > let x = x + 1 > you get a <<loop>> (or a deadlock). > Are there any other reasons? I am trying to debug monadic code which stores state information in a record maintaining several Data.Maps, but in vein so far. A state is modified/changed in several steps by a compound function i.e. changeA $ changeB $ changeC state Is code using mtl, records or Maps more prone to <<loop>> or does this not matter at all. How can I identify self-referencing thunks more easily? Is there any rule of thumb to prevent <<loop>>? Are there any less obvious newbie mistakes causing <<loop> then the one above? Any comments, experience, and tips are highly appreciated. Thanks, Martin

1 0