July 2004 - Haskell-Cafe

so how does one convert an IO a into an a ?
by Crypt Master 09 Jul '04

09 Jul '04

Hi Thanks for your help so far, but I am still not getting this IO stuff. After reading your previous help and reading several articles on it I still cant phathom how you convert the IO Int into an Int. One person mentioned how random just returns an interative program which when eveluated returns the Int. Also from the school of expression book he says " The right way to think of (>>=) above is simply this: It "Executes" e1 ..." in relation to "do pat <- e1 ...". so I have this: <code> rollDice :: IO Int rollDice = getStdRandom (randomR (1,6)) rl :: [Int] rl = [ (getRndNum x) | x <- [1..] ] getRndNum :: Int -> Int getRndNum x = do n <- rollDice return n </code> *PS Pretend return is correctly aligned under n. dont what ahppens in copy and paste* now my understanding therefore is that "do n <- rollDice" should execute the the itererative program returned by rollDice. So now n should be my Int since IO Int was a program which when evaluted returns an Int ? However this is what haskell thinks of my thoery: *** Term : getRndNum *** Type : Int -> IO (Maybe Int) *** Does not match : Int -> Int So I am still in IO Int land despite having used the >>= in the do syntax. Worse Still I am in IO (Maybe Int) land. Monads within Monads. In yours, and many other examples I found online, the results are always passed to print which seems to know how to deal with an IO Int. Is this specially coded or overloaded or something ? There are plenty of examples which use return like so: do k <- getKey w return k which is what I tried above to no avail. It seems awefully complicated just to get hold a simple Int, but naturally complicity is directly related to ones understanding. Mine is sumewhat lacking ... any help would be appreciated. Thanks, S _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail

10 11

state in the continuation monad...
by MR K P SCHUPKE 09 Jul '04

09 Jul '04

I am trying to model state in the continuation monad, such that each continuation recieves the current state as one of its arguments. The state must vary in type, which is why I am trying to use the continuation monad, but things don't seem to be going too well. To clarify... imagine the following sequence: do cont1 cont2 cont3 we may want the implicit parameter for cont1 to be an Int, but for it to pass a String to cont2 which passes (String,Int) to cont3 which finally returns something else. so: is it possible to write cont1 etc... ? can anybody tell me what its type would be? Keean.

3 2

Of types and constructors; a question of programming style
by Graham Klyne 08 Jul '04

08 Jul '04

When I'm designing datatypes for a Haskell program, I sometimes seem to end up with a slightly incoherent mixture of algebraic types and constructors. I'm wondering if anyone has worked out a principled way to decide when to introduce a new data type. Here's an example from something I'm working on: [[ data Event = Document DocURI Element | Element Name BaseURI Language Children Attributes LiIndex Subject | EndElement | Attribute Name AttributeVal | Text TextVal ]] (abbreviated from the original for discussion, and using arbitrary type names for the field types) Using this formulation, I have no access to the type of the different alternatives of the Union type thus defined. A different way of describing the type overcomes this limitation: [[ data Event = EVDocument Document | EVElement Element | EVEndElement EndElement | EVAttribute Attribute | EVText Text data Document = Document DocURI Element data Element = Element Name BaseURI Language Children Attributes LiIndex Subject data EndElement = EndElement data Attribute = Attribute Name AttributeVal data Text = Text TextVal ]] which seems to be rather repetitious. And I haven't even started to use the named field syntax here. Yet another alternative, if I'm not interested in field names, might be to use tuples and type synonyms for the alternative values: [[ data Event = Document EVDocument | Element EVElement | EndElement EVEndElement | Attribute EVAttribute | Text EVText type EVDocument = (DocURI,Element) type EVElement = (Name,BaseURI,Language,Children,Attributes,LiIndex,Subject) type EVEndElement = () type EVAttribute = (Name,AttributeVal) type EVText = TextVal ]] Is there any community consensus concerning what constitutes good style in such circumstances? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

4 4

List find-and-remove
by Graham Klyne 08 Jul '04

08 Jul '04

Once again, I find myself making code that I think may exist somewhere in the libraries: [[ -- list find and remove extract0 :: (a->Bool) -> [a] -> Maybe (a,[a]) extract0 p as = ex [] as where ex seen (a:more) | p a = Just (a,revcat seen more) | otherwise = ex (a:seen) more ex _ [] = Nothing extract :: (a->Bool) -> [a] -> Maybe (a,[a]) extract _ [] = Nothing extract p (a:as) | p a = Just (a,as) | otherwise = pref a (extract p as) where pref a1 (Just (a,as)) = Just (a,a1:as) pref _ Nothing = Nothing -- make list from reversed initial sublist and given trailing sublist revcat :: [a] -> [a] -> [a] revcat [] more = more revcat (a:as) more = revcat as (a:more) t1 = extract (==2) [1,2,3,4] == Just (2,[1,3,4]) t2 = extract (>2) [1,2,3,4] == Just (3,[1,2,4]) t3 = extract (>5) [1,2,3,4] == Nothing ts = and [t1,t2,t3] ]] (1) is there a function like 'extract'/'extract0' in the standard libraries? (2) if not, is there any significant difference in the efficiency of the above implementations? I think they both use linear time and space, but the 'extract0' performs a second traversal of (part of) the list to construct the result, where 'extract' has to pick apart and test the result from each recursive call. To my eye, the 'extract0' version looks better. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Inferred type is not general enough
by Ivan Tihonov 08 Jul '04

08 Jul '04

I start some ip networks related work in haskell and wrote two basic classes Location and Packet. Before writing IpLocation and IpPacket instances i have written simple TestLocation and TestPacket instances just to compile this and check for errors in class definitions. But looks like i misunderstand some haskell principles... ====================================================== class Location a where point :: a -> String class Packet a where source, destination :: Location b => a -> b size :: Num b => a -> b ------------------------------------------------------ data TestLocation = TestSource | TestDestination data TestPacket = TestPacket ------------------------------------------------------ instance Location TestLocation where point a = "location" instance Packet TestPacket where source p = TestSource destination p = TestDestination size p = 99 $ hugs Test.hs ERROR Test.hs:20 - Inferred type is not general enough *** Expression : source *** Expected type : (Packet TestPacket, Location a) => TestPacket -> a *** Inferred type : (Packet TestPacket, Location TestLocation) => TestPacket -> TestLocation ====================================================== But if i remove source and destination from class and instance definitions alone "size" compiles well. How write this in a haskell way?

4 5

RE: infered type does not typecheck
by Simon Peyton-Jones 08 Jul '04

08 Jul '04

Duncan Oleg's recent message to Haskell-Café tackles your real problem, but I thought I'd just say what is going on with your apparent bug below. Here's a much simpler example: class Foo a b where to :: a -> b fro :: b -> a -- foo :: forall b1 b a. (Foo a b, Foo a b1) => b -> b1 foo x = to (fro x) Without the type signature, the program typechecks "fine", and GHCi reports the type in the comment. But if you uncomment the type signature, typechecking fails. Why? It's because the type is really ambiguous. 'fro' converts from b to a, and 'to' converts back... but the 'a' is entirely lost in the process. It's very like the classic (show (read x)) example. So the type foo :: forall b1 b a. (Foo a b, Foo a b1) => b -> b1 is really unusable, because there is nothing to constrain 'a'. When you add the type signature, GHC can't establish the connection between the 'a' needed as the intermediate type in the (to (fro x)) composition and the 'a' in the type signature. You might argue that GHC should reject foo in the first place, and you'd be right, really. But it's hard in general to reject exactly and only the ambiguous cases (given functional dependencies and all that jazz), and I have not worked hard on that. But I grant that it's rather counter-intuitive that adding a type signature that GHC itself deduces goes wrong! You're right to count it a bug. Simon | This was posted to the Haskell list earlier, | http://www.haskell.org//pipermail/haskell/2004-June/014286.html | but just to record what appears to be a typechecker bug. | | I have a function with this type: | buildUArray' :: (Ix i, MArray (array s) a (ST s)) => | (i,i) -> (i -> a) -> ST s (array s i a) | | Then I ask ghci (6.2.1 and 6.3 recent cvs) the type of the following | function: | | buildUArray bounds f = do arr <- buildUArray' bounds f | unsafeFreeze arr | | ghci says: | buildUArray :: forall a i b s array. | (MArray (array s) a (ST s), Ix i, IArray b a) => | (i, i) -> (i -> a) -> ST s (b i a) | | However if I add this annotation back in the script, ghc complains: | | Could not deduce (MArray (array1 s) a (ST s)) | from the context (MArray (array s) a (ST s), Ix i, IArray b a) | arising from use of `unsafeFreeze' at BuildArray.hs:25 | Probable fix: | Add (MArray (array1 s) a (ST s)) | to the type signature(s) for `buildUArray' | Or add an instance declaration for (MArray (array1 s) a (ST s)) | In the result of a 'do' expression: unsafeFreeze arr | In the definition of `buildUArray': | buildUArray bounds f | = do | arr <- buildUArray' bounds f | unsafeFreeze arr

1 0

Re: [Haskell-cafe] Inferred type is not general enough
by Ivan Tihonov 08 Jul '04

08 Jul '04

Stefan Holdermans wrote: Huh. I'm really get stuck. Can someone write me working implementation of my crap?

2 1

Re: [Haskell-cafe] Inferred type is not general enough
by Ben Lippmeier 08 Jul '04

08 Jul '04

Ivan.. Uh.. by 'works' I meant 'compiles' :) Here is a fixed version.. As I understand it, the 2 parameter class (Location loc => Packet p loc) means "loc is a Location, and types p and loc are related by class Packet" with just that information, if you try (as you did) something like $ source TestPacket Then you've given the compiler the type for 'p' (TestPacket), but it won't go the distance and decide that type for 'loc' is TestLocation.. even though that's the only instance you've given it. You can tell the compiler that "The type of 'p' sets the type of 'loc'" with a "functional dependency".. which is the "| p -> loc" annotation at the end of the class definition in the new version below. There is a paper which covers exactly this problem, in detail. I suggest you read it (I did). "Type classes with functional dependencies", Mark P. Jones, 2000 You can get it from his homepage at, http://www.cse.ogi.edu/~mpj/ Ben. Ivan Tihonov wrote: > It compiles well, but doesn't work for me :( > BTW: (email answers are not always real-time :) ) new version: -------------------------------------- class Location a where point :: a -> String class Location loc => Packet p loc | p -> loc where source :: p -> loc destination :: p -> loc size :: Num b => p -> b ------------------------------------------------------ data TestLocation = TestSource | TestDestination deriving (Show) data TestPacket = TestPacket ------------------------------------------------------ instance Location TestLocation where point a = "location" instance Packet TestPacket TestLocation where source p = TestSource destination p = TestDestination size p = 99

1 0

Re: [Haskell-cafe] Folding function composition: L or R?
by Graham Klyne 07 Jul '04

07 Jul '04

At 14:24 07/07/04 +0200, Henning Thielemann wrote: >On Wed, 7 Jul 2004, Graham Klyne wrote: > > > [[ > > sss :: [ShowS] > > sss = map (++) ["abc","def","ghi","jkl"] > > > > ssr = foldr (.) id sss > > ssl = foldl (.) id sss > > > > sr = ssr "" > > sl = ssl "" > > > > -- sl == sr == "abcdefghijkl" > > -- is there any efficiency difference? > > ]] > > > > Conventional wisdom suggests that foldr is better, but I'm not sure if it > > really matters in this case. > >foldl performs worse, e.g. for infinite lists it will need infinite >time :-) Of course! And your answer makes me notice an important touchstone when dealing with such questions: "what happens with an infinite list?". Thanks! #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Folding function composition: L or R?
by Graham Klyne 07 Jul '04

07 Jul '04

I have a sequence of functions that I wish to fold together using function composition (.). Does it matter if I use foldl or foldr? e.g. [[ sss :: [ShowS] sss = map (++) ["abc","def","ghi","jkl"] ssr = foldr (.) id sss ssl = foldl (.) id sss sr = ssr "" sl = ssl "" -- sl == sr == "abcdefghijkl" -- is there any efficiency difference? ]] Conventional wisdom suggests that foldr is better, but I'm not sure if it really matters in this case. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1