May 2009 - Haskell-Cafe

Question on kind inference
by Vladimir Reshetnikov 31 May '09

31 May '09

Hi, Consider this Haskell code: ----------------------------------------------- class A a where foo :: a b class B a class (A a, B a) => C a ----------------------------------------------- GHC compiles it without errors, but Hugs rejects it: "Illegal type in class constraint". What is the correct behavior, and which part of the haskell 98 report explains this? Thanks, Vladimir

2 1

Re: [Haskell-cafe] Parsing command lines
by Kalman Noel 31 May '09

31 May '09

Patai Gergely schrieb: > is there a function that can safely split a command line into a FilePath > to the executable and its parameters? In the yi source code, in HConf.Utils, there's a function that does part of what you want, but maybe incorrectly (because I wrote it, and it traverses the string in a rather primtive way). -- | Break up a string the way a shell breaks up a command into arguments. -- Similar to 'words', but respects quotes and escaped spaces. TODO: Verify -- this function. shellWords :: String -> [String]

1 0

Haskell and symbolic references
by Patrick LeBoutillier 31 May '09

31 May '09

Hi all, Is it possible with Haskell to call a function whose name is contained in a String? Something like: five = call_func "add" [2, 3] If not, perhaps this is acheivable using FFI? Thanks a lot, Patrick Leboutillier -- ===================== Patrick LeBoutillier Rosemère, Québec, Canada

5 4

Re: [Haskell-cafe] Missing a "Deriving"?
by nowgate＠yahoo.com 31 May '09

31 May '09

Hi Ryan, Is there something missing or mislabeled in your post, because I don't see any definition of toDynamic. Michael --- On Sun, 5/31/09, Ryan Ingram <ryani.spam(a)gmail.com> wrote: From: Ryan Ingram <ryani.spam(a)gmail.com> Subject: Re: [Haskell-cafe] Missing a "Deriving"? To: "David Menendez" <dave(a)zednenem.com> Cc: "michael rice" <nowgate(a)yahoo.com>, haskell-cafe(a)haskell.org, "Miguel Mitrofanov" <miguelimo38(a)yandex.ru> Date: Sunday, May 31, 2009, 12:45 AM On Sat, May 30, 2009 at 6:33 PM, David Menendez <dave(a)zednenem.com> wrote: > *Main> :t searchAll > searchAll :: (Computation c) => Graph t t1 -> Int -> Int -> c [Int] > > The way searchAll is written, the choice of which functions to use > depends on the type variable c. That's determined by the calling > context of searchAll, which is why you need to provide a type > signature when using it at the GHCi command line. This is actually one of the most interesting and important things to "get" about typeclasses; it's not *just* like an interface, because the instance type can appear in the result of a function and *not* in the arguments at all. In contrast, in Java/C++, the method to use is always chosen by the object being called; one could argue that all of COM is an attempt to get around this problem. Some examples: > fromInteger :: Num a => Integer -> a > fromDynamic :: Typeable a => Dynamic -> Maybe a In both of these cases, the choice of which instance to use is made by the caller, and often automatically by type inference: > test x = case fromDynamic x of > Just s -> s == "hello" > Nothing -> False Now (test $ toDynamic "hello") = True, but (test $ toDynamic 'a') = False. Notice that I never directly specified what type "fromDynamic" should return; but the case statement forces it to return Maybe String, since I compare (s == "hello") -- ryan

2 1

Re: [Haskell-cafe] Missing a "Deriving"?
by michael rice 31 May '09

31 May '09

Belay that last question. I just realized that its the const function being used rather than a constant declaration in const Nothing and const []. MIchael --- On Sat, 5/30/09, David Menendez <dave(a)zednenem.com> wrote: From: David Menendez <dave(a)zednenem.com> Subject: Re: [Haskell-cafe] Missing a "Deriving"? To: "michael rice" <nowgate(a)yahoo.com> Cc: "Miguel Mitrofanov" <miguelimo38(a)yandex.ru>, haskell-cafe(a)haskell.org Date: Saturday, May 30, 2009, 9:33 PM On Sat, May 30, 2009 at 9:00 PM, michael rice <nowgate(a)yahoo.com> wrote: > That works. but it gives just a single solution [1,2,3] when there are > supposed to be two [[1,2,3],[1,4,3]]. Of course the code in YAHT may be in > error. Works for me. *Main> searchAll g 1 3 :: [[Int]] [[1,2,3],[1,4,3]] *Main> searchAll g 1 3 :: Maybe [Int] Just [1,2,3] *Main> searchAll g 1 3 :: Failable [Int] Success [1,2,3] > Also, how the heck does Haskell decide which "success", "failure", > "augment", and "combine" to use in function "searchAll", since there are > five possibilities. *Main> :t searchAll searchAll :: (Computation c) => Graph t t1 -> Int -> Int -> c [Int] The way searchAll is written, the choice of which functions to use depends on the type variable c. That's determined by the calling context of searchAll, which is why you need to provide a type signature when using it at the GHCi command line. -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

1 0

Re: [Haskell-cafe] Missing a "Deriving"?
by michael rice 31 May '09

31 May '09

I figured out the [[Int]] case for myself, but hadn't considered the Failure case. Thanks. In function "searchAll", given a calling context Failable [Int], for the line where search' [] = failure "no path" "failure" would be "Fail", a constructor that takes a String. Right? But using either of the other two contexts, where failure equals either const Nothing or const [] it would seem like that same string argument "no path" would be passed to either Nothing or [], which doesn't make any sense. Explanation? Michael --- On Sat, 5/30/09, David Menendez <dave(a)zednenem.com> wrote: From: David Menendez <dave(a)zednenem.com> Subject: Re: [Haskell-cafe] Missing a "Deriving"? To: "michael rice" <nowgate(a)yahoo.com> Cc: "Miguel Mitrofanov" <miguelimo38(a)yandex.ru>, haskell-cafe(a)haskell.org Date: Saturday, May 30, 2009, 9:33 PM On Sat, May 30, 2009 at 9:00 PM, michael rice <nowgate(a)yahoo.com> wrote: > That works. but it gives just a single solution [1,2,3] when there are > supposed to be two [[1,2,3],[1,4,3]]. Of course the code in YAHT may be in > error. Works for me. *Main> searchAll g 1 3 :: [[Int]] [[1,2,3],[1,4,3]] *Main> searchAll g 1 3 :: Maybe [Int] Just [1,2,3] *Main> searchAll g 1 3 :: Failable [Int] Success [1,2,3] > Also, how the heck does Haskell decide which "success", "failure", > "augment", and "combine" to use in function "searchAll", since there are > five possibilities. *Main> :t searchAll searchAll :: (Computation c) => Graph t t1 -> Int -> Int -> c [Int] The way searchAll is written, the choice of which functions to use depends on the type variable c. That's determined by the calling context of searchAll, which is why you need to provide a type signature when using it at the GHCi command line. -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

1 0

Re: [Haskell-cafe] Missing a "Deriving"?
by michael rice 31 May '09

31 May '09

Hi Miguel, That works. but it gives just a single solution [1,2,3] when there are supposed to be two [[1,2,3],[1,4,3]]. Of course the code in YAHT may be in error. Also, how the heck does Haskell decide which "success", "failure", "augment", and "combine" to use in function "searchAll", since there are five possibilities. MIchael --- On Sat, 5/30/09, Miguel Mitrofanov <miguelimo38(a)yandex.ru> wrote: From: Miguel Mitrofanov <miguelimo38(a)yandex.ru> Subject: Re: [Haskell-cafe] Missing a "Deriving"? To: "michael rice" <nowgate(a)yahoo.com> Cc: haskell-cafe(a)haskell.org Date: Saturday, May 30, 2009, 5:36 PM It's trying to 'Show' the 'c [Int]' type, but doesn't know which 'c' to use; so it's trying to find a generic instance, which doesn't exist. You can't fix this with 'deriving' or anything like this; instead, provide the type annotation like this: *Main> searchAll g 1 3 :: Maybe [Int] On 31 May 2009, at 00:50, michael rice wrote: > The following code is from Section 8.4.2, pgs. 111-112 (PDF paging) of YAHT. > > It compiles fine, but upon trying it I get the following error message. > > It seems to be trying to 'Show' the Computation class but I'm not sure where to put the 'Deriving'. > > Michael > > > ============ > > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > [1 of 1] Compiling Main ( graph4.hs, interpreted ) > Ok, modules loaded: Main. > *Main> let g = Graph [(1,'a'),(2,'b'),(3,'c'),(4,'d')] [(1,2,'p'),(2,3,'q'),(1,4,'r'),(4,3,'s')] > *Main> searchAll g 1 3 > > <interactive>:1:0: > No instance for (Show (c [Int])) > arising from a use of `print' at <interactive>:1:0-14 > Possible fix: add an instance declaration for (Show (c [Int])) > In a stmt of a 'do' expression: print it > > ============================ > > data Failable a = Success a | Fail String deriving (Show) > > data Graph v e = Graph [(Int,v)] [(Int,Int,e)] > > class Computation c where > success :: a -> c a > failure :: String -> c a > augment :: c a -> (a -> c b) -> c b > combine :: c a -> c a -> c a > > instance Computation Maybe where > success = Just > failure = const Nothing > augment (Just x) f = f x > augment Nothing _ = Nothing > combine Nothing y = y > combine x _ = x > > instance Computation Failable where > success = Success > failure = Fail > augment (Success x) f = f x > augment (Fail s) _ = Fail s > combine (Fail _) y = y > combine x _ = x > > instance Computation [] where > success a = [a] > failure = const [] > augment l f = concat (map f l) > combine = (++) > > searchAll g@(Graph vl el) src dst > | src == dst = success [src] > | otherwise = search' el > where search' [] = failure "no path" > search' ((u,v,_):es) > | src == u = (searchAll g v dst `augment` > (success . (u:))) > `combine` search' es > | otherwise = search' es > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

3 2

HPC and derived instances
by Felipe Lessa 30 May '09

30 May '09

Hello! Why isn't there an option to control whether HPC, the Haskell Program Coverage, will consider derived instances "coverable". I'm using it and my top level coverage is 52% while my expression coverage is at 92%. Looking carefully we see that most non-tested top level definitions are derived Show, Eq and Ord instances that I always derive for most data types (as this is a library). I think it is nice that it recognizes class instances, but there should be a flag to ignore at least the derived ones. Am I missing something? Thanks! :) -- Felipe.

1 0

[] == []
by Paul Keir 30 May '09

30 May '09

Hi all, GHC is not happy with this: f = [] == [] nor this: f' = ([]::(Eq a) => [a]) == ([]::(Eq a) => [a]) but this is OK: f'' = ([]::[Integer]) == ([]::[Integer]) GHCI is comfortable with [] == [], so why not GHC? 'Just curious. Cheers, Paul

5 5

get Scale of window in HOpenGL?
by yu yang 30 May '09

30 May '09

Hi, I want to move one object to the border of window, then go back to the start point. Does anyone one have an idea to implement it ? Thank you! ___________________________________________________________ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/

1 0