- Haskell-Cafe - Haskell.org

Process properties as global values
by Volker Wysk 12 Jul '04

12 Jul '04

Hi I'm just wondering, why haven't process properties (such as the command line arguments, or the parent process id), which are inherently global, been made global values in the Haskell standard? You could avoid needlessly carrying around these values, you wouldn't need to lift some functions into the IO monad... For instance, command line argument parsing could look something like this: import qualified System data ParsedArgs = ParsedArgs { pa_myflag :: Bool; ... } | Failure parsed_args :: ParsedArgs parsed_args = (... using System.argv ...) myflag = pa_myflag parsed_args main = do when (parsed_args == Failure) $ ... ... You can get the same effect by using unsafePerformIO. It would still be nice having this in the standard. Greetings, V.W. -- Volker Wysk <post(a)volker-wysk.de> http://www.volker-wysk.de

6 7

Giving up imperative habits....
by paolo veronelli 10 Jul '04

10 Jul '04

Usually I tend not to give much information to a subroutine intending to restrict its liberty of touching the calling information..... So if I have an instance Inst which should be changed by an outside-Inst computation Sub and I'm calling Sub with Sub(I'),I try to build the story so that Sub can only read Inst or a part of it (I') and return some specially structured information which then I use "inside" Inst to change Inst's state (horribble speech). The feeling I get with Haskell, is that S should have the freedom of changing I and return just I (changed). Is it any right ?? grazie Paolino -- ....lotta dura per la verdura

1 0

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

10 Jul '04

Hi Thanks for all the usefull responses, from theory to practical :-). I am busy digesting it all. I have more questions, but more and more I can answer them myself :-) Till the next misunderstanding ;-) C _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

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