Re: [Haskell-cafe] Code review: efficiency question
Evan Martin wrote: I remember reading a tutorial that pointed out that you can often avoid explicit recusion in Haskell and instead use higher-level operators. For your code, I think drawModals = foldr (flip ()) (return ()) . map drawModal works(?). I think it would be foldl so that the (return()) would be nested as the leftmost element. Thanks for pointing out this point-free version of drawModals, although for readability at the moment I think I still prefer just to use mapM_ drawModal (reverse cs) Best regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code review: efficiency question
Hello Brian, Tuesday, May 2, 2006, 3:12:48 AM, you wrote: -- Prolog style coding... drawModals :: [Control] - ManagerM () drawModals [] = return () drawModals (c:cs) = do drawModals cs drawModal c imho, it's typical functional style, but without using higher-level functions mapM_ drawModal (reverse cs) However, while this looks more elegant, it is less efficient? In other words, how much optimization can one assume when writing Haskell code? ghc will don't translate your later code into the former one. although in general ghc (but not other haskell compilers, afaik) is very good in replacing one code with another faster one and in particular in translating list producer + list consumer into straightforward loop how about this solution: reverseMapM_ f (x:xs) = do reverseMapM_ f xs; f x reverseMapM_ f [] = return () or you can define `reverseMapM_` via fold, if you have better FP skills than me :) I'm trying to get a rough idea so I can decide whether to write helper functions such as drawModals in future or whether I should always just use the most elegant code instead. Any ideas? you will laugh, but speed of your two solutions depends on so many factors (including size of CPU cache) that noone can say that is better in general. although for small lists reverseMapM_ should be faster than reverse+mapM. what will be faster - using of higher-order function or direct recursion, i can't say, it's a really counter-intuitive area of ghc optimizer :) of course, i don't think that all that really matters for your program (drawing should anyway need much more time than looping). just use higher-level approach (that makes code simpler to write, understand and maintain) and don't bother your mind :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: database access recommendation
Bulat Ziganshin wrote: Hello Donald, Friday, April 28, 2006, 12:29:38 PM, you wrote: I looked at http://www.haskell.org/haskellwiki/Libraries_and_tools, and suffice it to say that this page don't reflects current state of the art. during many years it was not updated and when it was moved to the wiki half-year ago it's contents remains the stone-age About a month ago I went through the entire HWN archives, the haskell@ archives back to 1990 (Check the Old_news page!) and the last HCAR, adding over 100 entries to the libraries page. So, I argue it is the most complete list we have. GREAT! but you don't announced this work on the haskell list, so noone can know about it Point your favourite RSS reader at http://haskell.org/haskellwiki/?title=Special:Recentchangesfeed=atom and watch the changes! Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GetOpt
Tomasz Zielonka wrote: and handle options as functions from Config to Config: I find this approach very convenient, but I push it a bit further. Some time ago I wrote a small article about this: http://www.haskell.org/pipermail/haskell/2004-January/013412.html [from there] -- Here we thread startOptions through all supplied option actions opts - foldl (=) (return startOptions) actions So the order in actions is important and therefore the order of options on the commandline is important. But how to handle dependencies between options using this technique? I can image two solutions: 1: Every dependency 'a implies b' has to be checked in both functions, the one for a and the one for b. 2: An order for the actions has to be specified, maybe by decorating the option list with priorities. But both solutions seems to be tedious and error prone. In contrast the sum-type technique first reads all options and then post-processes the complete set. Here the order of options on the commandline has no impact on the final result. Regards, Mirko Rahn -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ --- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Summer of Code - Student Application Form
Hi, it was just published the student application form, you can find it at: http://code.google.com/soc/student_step1.html I hope we will be collecting good Haskell applications from students :-) I am very happy to see how many did signed up on the People page as now: http://hackage.haskell.org/trac/summer-of-code/ Keep on writing! Paolo. -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GetOpt
On Tue, May 02, 2006 at 02:27:28PM +0200, Mirko Rahn wrote: But how to handle dependencies between options using this technique? I can image two solutions: 1: Every dependency 'a implies b' has to be checked in both functions, the one for a and the one for b. 2: An order for the actions has to be specified, maybe by decorating the option list with priorities. 3: Handle some (not all) options in a sum-type fashion In contrast the sum-type technique first reads all options and then post-processes the complete set. Here the order of options on the commandline has no impact on the final result. I forgot to show that you can still use old style option handling for some options. This way you can gradually move from sum-type style to product-type style. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell + Windows API = wuh?
Ello. I'm looking for a way to interface the Windows API with Haskell in order to write a Win32 console handler thingy. I don't know anything about the Haskell Foreign Function Interface beyond what its name implies and that it's an extension to Haskell 98 (or is it?). So just where do I start? --ihope ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell + Windows API = wuh?
Hi, Pretty much every Haskell implementation supports the FFI - its a standardised Haskell 98 extension. Take a look at the System.Win32 library which is a wrapper round the Windows API. If you have a reference to the Win32 API (i.e. MSDN) then the API looks like a very straightforward wrapper. Thanks Neil On 5/2/06, ihope [EMAIL PROTECTED] wrote: Ello. I'm looking for a way to interface the Windows API with Haskell in order to write a Win32 console handler thingy. I don't know anything about the Haskell Foreign Function Interface beyond what its name implies and that it's an extension to Haskell 98 (or is it?). So just where do I start? --ihope ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
