I'm relatively new to Haskell and am trying to implement nim, I have written all the code but cannot for the life of me work out the type bindings, the code is long but I was hoping someone could explain to me what the bindings for each function are and why? Thanks.nim :: ? nim = do putStrLn "Enter first player's name!" n1 <- getLine putStrLn "Enter second player's name!" n2 <- getLine putStrLn "Enter pile amounts, enter 0 to stop adding piles." ps <- getPiles  w <- play n1 n2 ps f <- (w ++ " has won!") return f play :: ? play n1 n2 ps = do p <- (n1 ++ "'s Turn! \n") putStrLn p displayGame ps m <- getMove nps <- (takeAway ps (getFst m) (getSnd m)) if won ps == True then return n1 else play n2 n1 nps getPiles :: ? getPiles xs = do putStr "Enter amount in next pile : " x <- (read getLine) if x == 0 then do xs ++ [x] getPiles xs else xs getFst :: (Int,Int) -> Int getFst (x,_) = x getSnd :: (Int,Int) -> Int getSnd (_,x) = x
The bindings for other functions used are -won :: [Int] -> Bool takeAway :: [Int] -> Int -> Int -> [Int] getMove :: IO (Int,Int) displayGame :: [Int] -> IO ()
I realize that this might be allot to ask but I have hit a dead end and my "teammates" are of no help.submitted by con7con
[link] [22 comments]
[link] [35 comments]
Anyone else feel that runStateT and friends (execState, runReader etc) would be better flipped? I always find myself writing flip runStateT, because I never need to parameterise the state variable and it's convenient to use multiline do syntax for the action. Just curious.submitted by scottansan
[link] [18 comments]
Haskell people, any ideas on how I can refactor this code? : http://tinyurl.com/l38hdp3 I use a lot of fromJust and isNothing, which looks horrible, but I cannot pattern match on them because I'm using guards. Since I have a lot of guards that are kinda irregular, using nested ifs seemed worse. Not to mention that the order of the guards matters. I don't see how to pattern match the Maybe values. The current version works but it's ugly. I wonder what you'd do. (By the way, there are a lot of tests in the repo that you can run. The tests cover the requirements of Turkish syllabification) Thanks!submitted by wavesofthought
[link] [14 comments]
Hello all! I am trying to build the program geordi (specifically the clang branch) which can be found here: https://github.com/Eelis/geordi/tree/clang when i run it though i get these errors: http://paste.ubuntu.com/8778876/ . I am on ubuntu 14.04 64 bit, and got ghc and cabal with apt-get. Any help would be appreaciated! thanks! (I tried fixing the errors myself but im more of an oop/structural language guy... functional languages scare me)submitted by DTSCode
[link] [7 comments]
My significant other is running Debian stable on her laptop, and it has worked fine for quite a while. But since a week or two, she could not access her University IMAP account via Evolution. Obviously quite a showstopper!
Today I had a closer look, and my suspicion was that the University changed their SSL configuration due to the recent POODLE attack and that Evolution was incompatible with that. After some more searching, I found that Ubuntu had applied a patch, originally from Fedora, two weeks ago. For Debian, there is a bug report but no sign of action.
So I fetched the sources, applied the patch, built the package, installed it and things were working again. Yay for that! But this is obviously not the best way to handle such issues.
I know that Debian is volunteer driven and we often lack the manpower for certain things, so I don’t want to rant about this particular issue. I also continue to be a happy user of Debian unstable on my laptop, and Debian stable on my servers. But I seriously wonder: Can I really recommend Debian stable to users, for their laptops and desktops? If not, what are the alternatives? Ubuntu obviously comes to mind, having some full-time staff for such issues... But that would be giving up on promoting Debian as the universal operating system.
Update (2010-11-3): Laney just uploaded a fixed package. Thanks!
Coming to learn a functional programming which has much attention nowadays and also being mostly a GUI programmer I found a lot of libraries in Haskell (and other FP languages) which decorate an existing and popular choices for writing a cross-platform UI (Qt, Gtk, wx etc). Decoration happens in many possible styles be it FRP, FFI, whatever else I missed.
But I never found a more or less modern library which was built from ground up using an FP idioms and best practices.
I wonder why is it so? Is it because FRP is good for this but kinda not yet figured out exactly? Or is it because FP was used mainly in data manipulation or algorithmic tasks so far, but less in UI? Or some other reason?
Is it even possible to build such a library which would be modern, functional and provide a comprehensive set of widgets to work with? Is it just a question of manpower?
Or did I miss any existing effort to build such a library?submitted by dimsuz
[link] [19 comments]
henn v.t. to write or rewrite (Haskell code) naming types 'T' and classes 'C': to write or rewrite (code, etc.) in any annoying personal idiom
- "It's henned -- those are different 'C's and 'T's."
- "numeric-prelude could be a viable alternative if someone were to dehenn it."
- "It's OK to henn if you're never going to publish it."
- "I do wish he'd stop henning all his packages."
[link] [10 comments]
Yes, all of your Halloween fears are coming true. But this time it's "Migration downtime, not "omg-phone-ringing-things-are-busted downtime" like it was earlier today.
But didn't we do this before?
So, we talked about this a few weeks ago, and Duncan and I attempted it. But didn't quite complete it due to some performance snags. But we're going to do the move in the mean time anyway - it's mostly just a switch being flipped at this point. Performance snags are preferable to "not working"-snags. Duncan has also helpfully identified some server issues in the past two weeks that should help us too in the long run.
Davean and I will do the migration tomorrow - but we will be available in case something catastrophic goes wrong (fingers crossed). Ping #haskell-infrastructure on freenode if you want to complain to us or give moral support or whatnot.
The status site will be kept fairly up to date, and it has the current expected migration timelines already listed in the top (see UTC timeframe): https://status.haskell.org/aseipp
[link] [1 comment]
I've grown quite attached to using vi keybindings in bash, and I have custom vi keybinds in my ~/.inputrc, most notably rebinding "jk" to escape.
I want this functionality in ghci. So far, I've seen a few options to achieve this:
This seems like exactly what I want; wrapping ghci in readline against its wishes. Problems: * rlwrap ghci has no effect. Of course. * rlwrap -a ghci gives me all of my keybindings, but if I ever accidentally wrap a line, say goodbye to that tmux pane. I usually end up having to hit Ctrl-C 5 times and the giving up with Ctrl-D.
I have "editMode: Vi" in my ~/.haskeline file. This sort of has the desired effect, but is unusable for two reasons. * I haven't figured out how to remap "jk" to get to normal mode. * Even when I hit ESC or Ctrl-[ manually, pressing "k" twice in a row quickly will go up one line, then insert the letter "k". This is wrong. I can sometimes get history to work if I wait long enough before pressing "k" the second time, but it's finicky.
Have any other Vi-mode addicts successfully tamed ghci? I thought of asking /r/vim or /r/commandline, but really it's the haskeline library that's causing all of this trouble, and only people with haskell experience would know how to fix it.submitted by the_noodle
[link] [12 comments]
Welcome to the GHC Weekly news. And it's just in time before you go out and eat lots of candy and food.
- David Feuer and Joachim Brietner spent some time this past week talking about more optimizations for Haskell code for fusing code, and creating better consumers and producers. This work includes optimizations of "One shot lambdas" (lambdas used at most once) and Call Arity, which was implemented by Joachim at Microsoft Research. The thread is here - https://www.haskell.org/pipermail/ghc-devs/2014-October/006901.html
The current situation is that Call Arity and One shot analysis tends to have good combined results for exploiting more fusion opportunities, but sometimes these backfire. As a result, Joachim and David have worked on improving the situation - particularly by letting programmers help with a new oneShot primitive (in Phab:D392 & Phab:D393).
- Herbert Valerio Riedel opened up a discussion about the origins of code contributions. In short, we'd like to have some stronger ground to stand on in the face of contributions from contributors - the origin of a change and its legal status is a bit nebulous. The thread is here: https://www.haskell.org/pipermail/ghc-devs/2014-October/006959.html
Overall, there's been a lot of separate points made, including CLAs (unlikely), "Developer Certificates of Origin" a la the Linux Kernel, and reworking how we mark up header files, and keep track of GHC's long history of authors. If you work on a big project where some of these concerns are real, we'd like to hear what you have to say!
- Gintautas Milauskas has done some fantastic work for GHC on Windows lately, including fixing tests, improving the build, and making things a lot more reasonable to use. With his work, we hope GHC 7.10 will finally ship an updated MinGW compiler (a long requested feature), and have a lot of good fixes for windows. Thank you, Gintautas!
- And on that note, the call for Windows developers rages on - it looks like Gintautaus, Austin, Simon, and others will be meeting to discuss the best way to tackle our current woes. Are you a Windows user? Please give us input - having input is a crucial part of the decision making process, so let us know.
- Jan Stolarek had a question about core2core - a lot of questions, in fact. What's the difference between demand, strictness, and cardinality analylsis? Does the demand analyzer change things? And what's going on in some of the implementation? A good read if you're interested in deep GHC optimization magic: https://www.haskell.org/pipermail/ghc-devs/2014-October/006968.html
- Peter Wortmann has put up the new DWARF generation patches for review, in Phab:D396. This is one of the major components we still plan on landing in 7.10, and with a few weeks to spare, it looks like we can make sure it's merged for the STABLE freeze!
- There have been a lot of good changes in the tree this past week:
Thanks to Michael Orlitzky, we plan on adding doctest examples to more modules in 7.10, and increase that coverage further. This is *really* important work, but very low fruit - thanks a ton Michael!
Data.Bifunctor is now inside base! (Phab:D336)
atomicModifyIORef' has been optimized with excellent speedups (as much as 1.7x to 1.4x, depending on the RTS used), thanks to some older work by Patrick Palka (Phab:D315). GHC's internals have been reworked to unwire Integer from GHC, leading not only to a code cleanup, but laying the foundation for further GMP (and non-GMP!) related Integer improvements (Phab:D351).
David Feuer and Joachim have been relentless in improving fusion opportunities, including the performance of take, isSuffixOf, and more prelude improvements, spread over nearly half a dozen patches. And this doesn't even include the work on improving oneShot or Call Arity!
In a slight change to base semantics, David Feuer also finally fixed #9236. This is a change that can expose latent bugs in your program (as it did for Haddock), so be sure to test thoroughly with 7.10 (Phab:D327).
GHC now has support for a new __GLASGOW_HASKELL_TH__ macro, primarily useful for testing bootstrap compilers, or compilers which don't support GHCi.
And there have been many closed tickets: #9549, #9593, #9720, #9031, #8345, #9439, #9435, #8825, #9006, #9417, #9727, #2104, #9676, #2628, #9510, #9740, #9734, #9367, #9726, #7984, #9230, #9681, #9747, and #9236.