September 2011 - Haskell-Cafe

ghc 7.0.3 view patterns and exhaustiveness
by Richard Cobbe 21 Sep '11

21 Sep '11

I'm starting to play around with GHC's support for view patterns, and I'm running into what appears to be an annoying limitation of the implementation. GHC 7.0.3 (32-bit), MacOS 10.6.8. First module; defines an abstract type & provides a (trivial) view for it. module Term(Term, TermView(..), view) where data Term = TVar String | TApp Term Term | TLam String Term data TermView = Var String | App Term Term | Lam String Term view :: Term -> TermView view (TVar x) = Var x view (TApp rator rand) = App rator rand view (TLam x body) = Lam x body Second module tries to use the view in a trivial function: {-# LANGUAGE ViewPatterns #-} module Client where import Term numVarRefs :: Term -> Integer numVarRefs (view -> Var _) = 1 numVarRefs (view -> App rator rand) = numVarRefs rator + numVarRefs rand numVarRefs (view -> Lam _ body) = numVarRefs body -- numVarRefs (view -> _) = error "bogus" f :: TermView -> Integer f (Var _) = 1 f (App rator rand) = f (view rator) + f (view rand) f (Lam _ body) = f (view body) GHCI complains when trying to load this second module: Client.hs:8:1: Warning: Pattern match(es) are non-exhaustive In an equation for `numVarRefs': Patterns not matched: _ (I have ":set -fwarn-incomplete-patterns" in my .ghci.) I wrote 'f' to make sure that my patterns for TermView are indeed exhaustive, and GHC doesn't complain about it all. If I uncomment the last definition for numVarRefs, the warning goes away. I did some searching around on the web, in the mailing list archives, and in the GHC bug database, and I see that early on, views had trouble giving useful diagnostics for overlapping or non-exhaustive patterns, but most of those problems seem to have been fixed. I also couldn't find a bug report for precisely this situation -- #4439 is the closest, but I'm not using existential types here at all. Should I file a bug, or am I overlooking something simple? Or is this a known limitation of the current implementation? Thanks, Richard

3 2

stack overflow pain
by Tim Docker 21 Sep '11

21 Sep '11

I'm getting a stack overflow exception in code like this: -- applyAction :: A -> IO [B] .... vs <- fmap concat $ mapM applyAction sas return vs I don't get it if I change the code to this: -- applyAction :: A -> IO [B] .... mapM_ applyAction sas return [] But of course, I need the results from the actions. I know that the returned list contains approximately 1 million items. Any suggestions on how I should rewrite the first code snippet to not blow the stack? I do find debugging stack overflow errors quite difficult - with little information from the runtime I'm often left guessing which parts of a large codebase might be causing them. Note that there's plenty of heap space available, it's the evaluation stack that is being used up. I could run with -K to increase the size of the stack, but if possible I'd rather solve this in the code. Thanks for any pointers. Tim

7 7

hackage library info
by kioto mitsubisi 21 Sep '11

21 Sep '11

Hi, I want to ask a question about hackage which contains additional libraries to Haskell. Is there a mechanism that will help developer to choose a library among the others? I mean, there are several packages that may do the same thing in hackage and to choose one among the others, developer may want to have more information about the library such as other developers' ratings and comments, activity of development of the library, etc so that one can choose the better alternative. Is there a mechanism for that or is there a plan to add these to the hackage? Thanks

6 5

poles/residues -> FIR tap weights ?
by Captain Freako 21 Sep '11

21 Sep '11

Anyone know of a Haskell package containing a function for converting a list of pole/residue pairs into FIR filter tap weights? Thanks, -db

1 0

Parsec line number off-by-one
by Ben Gamari 21 Sep '11

21 Sep '11

Recently I've been playing around with Parsec for a simple parsing project. While I was able to quickly construct my grammar (simplified version attached), getting it working has been a bit tricky. In particular, I am now stuck trying to figure out why Parsec is mis-reporting line numbers. Parsec seems convinced that line 12 of my input (also attached) has a "%" character, $ runghc Test.hs Left "(unknown)" (line 12, column 1): unexpected "%" expecting space or atom name while my file clearly disagrees, 10 %FLAG ATOM_NAME 11 %FORMAT(20a4) 12 C1 H1 C2 H2 C3 H3 C4 H4 C5 C6 C7 C8 N1 C9 H9 C10 H10 C11 H11 C12 13 H12 C13 H13 C14 C15 N2 C16 C17 C29 H18 C19 H19 C20 H20 C21 H21 C22 H221H222H223 ... 18 %FLAG CHARGE 19 %FORMAT(5E16.8) The task here is to identify the block of data lines (lines 12-17), ending at the beginning of the next block (starting with "%"). It seems likely that my problem stems from the fact that I use "try" to accomplish this but this is as far as I can reason. Any ideas what might cause this sort of off-by-one? Does anyone see a better (i.e. working) way to formulate my grammar? Any and all help would be greatly appreciated. Thanks. Cheers, - Ben

3 4

Re: [Haskell-cafe] instance Enum Double considered not entirely great?
by John Lato 21 Sep '11

21 Sep '11

> From: Casey McCann <cam(a)uptoisomorphism.net> > <CAJ5riwLLu=wAFXm8VPnqRG2Daxxgf=UpgxzCHydMeBGNgixTFQ(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Sep 20, 2011 at 8:20 PM, Daniel Fischer > <daniel.is.fischer(a)googlemail.com> wrote: > >> However, nowadays I tend to think that making the Eq and Ord instances >> well-behaved (wrt the class contract) and having separate IEEE comparisons >> would overall be preferable. >> There is still the question whether all NaNs should be considered equal or >> not [and where Ord should place NaNs]. > > IEEE semantics are incompatible with Ord regardless. The problem can > be fixed by changing Ord, removing the instance completely, or > changing the instance to ignore the IEEE spec. I think the latter is > the least bad option in the big picture. > > I still don't see why it makes sense to add separate IEEE comparisons > instead of just adding a standard partial order class, though. Surely > posets are common enough to justify the abstraction, and it surprises > me that one isn't already included. No doubt there are at least three > or four different partial ordering classes on Hackage already. I agree with this already, and will agree more strongly if ConstraintKinds become widely available. > >> Google suggests "Exception for NaN" from May. > > Ah, yes, wherein someone suggested that comparing to NaN should be a > runtime error rather than give incorrect results. A strictly more > correct approach, but not one I find satisfactory... I would consider this better than the current situation. At least your sets wouldn't be silently corrupted. John L.

1 0

Re: [Haskell-cafe] Strange No instance error with cabal install
by Rune Harder Bak 21 Sep '11

21 Sep '11

Sorry, forgot to send to the list, But everything works today, and the commit was pulled from aeson to aeson-native, so that must have been it. Thanks! On Wed, Sep 21, 2011 at 8:20 AM, Rune Harder Bak <rune(a)bak.dk> wrote: > So you are saying, that this is basically because he has other version > of different packages, > not providing the same instances, that makes sense. > The other problem was no instance for Default (Request R) (Request > from Network.Wai) > It was provided by http-enumerator, but maybe not in his version of the package. > > I tried with aeson-native after you post without look, but I see a new > one has been released now. > Going to try it today. > Thanks! > > > On Tue, Sep 20, 2011 at 2:00 PM, Roel van Dijk <vandijk.roel(a)gmail.com> wrote: >> I see the aeson version with the stricter dependency on deepseq < 1.2 >> is now also released on hackage: >> >> http://hackage.haskell.org/package/aeson-0.3.2.12 >> >

1 0

Typhoon
by Kazu Yamamoto 20 Sep '11

20 Sep '11

Hello, To those who are in Tokyo for ICFP: The typhoon is likely to come after 16:00 today. Many students and workers will go home earlier this afternoon. It's Japanse style. If typhoon comes, umbrella does not work. Please stay in your building. You should understand all traffic transportation will stop. Even blackout would happen. Please please don't underestimate the typhoon. Typhoon info: http://www.jma.go.jp/en/typh/ http://weathernews.jp/satellite/ Rain visual info: http://tokyo-ame.jwa.or.jp/en/index.html Please don't panic. Stay in your building for about two hours. Enjoy slow life. --Kazu

1 0

Animas/Yampa - Using Zip as a Routing Function in a Parallel Switch with Feedback
by M. George Hansen 20 Sep '11

20 Sep '11

Greetings, I've been playing around with functional reactive programming using Animas/Yampa and ran into a strange situation. I'm using a parallel switch to route input to a collection of signal functions and using the output as feedback (to simulate state). Everything works as expected until I attempt to use zip as a routing function (i.e. pair each element of input with a signal function). Using zip as a routing function causes the program to enter an infinite loop when it evaluates the output from the parallel switch. Here is a minimal program that fails to terminate when using zip as a routing function: ----------------------------------------------------------------------------------------- {-# LANGUAGE Arrows #-} module LoopingTest ( ) where import Control.Arrow import FRP.Animas main = embed (process []) ([42], []) process :: [Activity] -> SF [InputEvent] SystemOutput process activities = proc inputEvents -> do rec let senses = map (\state -> (inputEvents, state)) states states <- par route activities -< senses returnA -< states route :: [Sense] -> [sf] -> [(Sense, sf)] -- route a sfs = fmap (\sf -> (head a, sf)) sfs route = zip type Activity = SF Sense State type InputEvent = Integer type State = [Integer] type Sense = ([InputEvent], State) type SystemInput = ([InputEvent], [State]) type SystemOutput = [State] ----------------------------------------------------------------------------------------- If you run the main function as-is the program will run forever, but if you change the route function to use the commented definition instead of zip the program terminates normally. I simply cannot wrap my brain around this issue - zip normally works just fine with infinite lists as long as one of the lists is finite, and in this case the number of Activity signal functions is known at compile time to be finite. I can't find anything conceptually wrong with using zip as a routing function either. If anyone has any thoughts I would be very grateful. -- M. George Hansen technopolitica(a)gmail.com

2 3

Fwd: Klocwork eNews: Secure Coding for C/C++
by Vasili I. Galchin 20 Sep '11

20 Sep '11

Hello, I get so frustrated trying to convince managers and colleagues of the efficacy of FPLs. Below speaks volumes about the "type safety" of C and C++. It is a bandaid approach. Vasili --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------- Forwarded message ---------- Date: Tue, Sep 20, 2011 at 9:14 AM Subject: Klocwork eNews: Secure Coding for C/C++ To: vigalchin(a)gmail.com ** [image: Klocwork eNewsletter - September 2011] eLEARNING Secure Coding for C/C++ When it comes to security attacks, the network used to be the prime target. But the attack profile has changed. Now security is a software problem too, with the number of software security vulnerabilities growing every year. As a result, the pressure on software developers to create secure software has never been greater. Brush up on the fundamentals of secure coding with this no charge, interactive eLearning course<http://mkto-d0052.com/track?type=click&enid=bWFpbGluZ2lkPWtsb2N3b3JrQmV0YWN…> : - Get the latest secure coding best practices - Learn nine tested secure coding techniques - See how to avoid common buffer overflows *This is a must-see course – view it today!*<http://mkto-d0052.com/track?type=click&enid=bWFpbGluZ2lkPWtsb2N3b3JrQmV0YWN…> SOCIAL MEDIA Follow Klocwork Do you know that Klocwork participates in all your favorite social media channels? Get quick updates from us and see what we're talking about by following us on Facebook, LinkedIn and Twitter. Check out our recent blog posts and links to our social media pages under the *Follow Us* section on www.klocwork.com<http://mkto-d0052.com/track?type=click&enid=bWFpbGluZ2lkPWtsb2N3b3JrQmV0YWN…> . BLOG Join the Discussion *Klocwork University consolidates learning resources into a single roster<http://mkto-d0052.com/track?type=click&enid=bWFpbGluZ2lkPWtsb2N3b3JrQmV0YWN…> * Your one stop for self-paced online learning. *Squeezing max from the 'try/finally' blocks<http://mkto-d0052.com/track?type=click&enid=bWFpbGluZ2lkPWtsb2N3b3JrQmV0YWN…> * Tips on handling resources in Java. *Importance of MISRA<http://mkto-d0052.com/track?type=click&enid=bWFpbGluZ2lkPWtsb2N3b3JrQmV0YWN…> * Klocwork's MISRA support is important to customers. Klocwork | 15 New England Executive Park | Burlington, MA 01803 1.866.556.2967 | www.klocwork.com<http://mkto-d0052.com/track?type=click&enid=bWFpbGluZ2lkPWtsb2N3b3JrQmV0YWN…> © 2011 Klocwork. All rights reserved. If you no longer wish to receive these emails, click on the following link: Unsubscribe<http://resources.klocwork.com/UnsubscribePage.html?mkt_unsubscribe=1&mkt_to…>

1 0