- Haskell-Cafe - Haskell.org

coercion to Int
by james pentland 01 Jan '05

01 Jan '05

what coercion can i use to get the below program to compile? i see class (Real a, Fractional a) => RealFrac a where round :: (Integral b) => a -> b and class (Fractional a) => Floating a where sqrt :: a -> a various combinations of fromInteger, toInteger do not help. fnK_ :: Int -> Int fnK_ x = round (sqrt x) -- line 2 Hugs session for: H:\Program Files\Hugs98\lib\Prelude.hs Prelude> :load xva Reading file "xva.hs": Type checking ERROR "xva.hs":2 - Instances of (RealFrac Int, Floating Int) required for definition of fnK_ __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

4 3

coercion to Int
by james pentland 31 Dec '04

31 Dec '04

what coercion can i use to get the below program to compile? i see class (Real a, Fractional a) => RealFrac a where round :: (Integral b) => a -> b and class (Fractional a) => Floating a where sqrt :: a -> a fillK_ :: Int -> Int fillK_ x = round (sqrt x) -- line 2 Hugs session for: H:\Program Files\Hugs98\lib\Prelude.hs Prelude> :load xva Reading file "xva.hs": Type checking ERROR "xva.hs":2 - Instances of (RealFrac Int, Floating Int) required for definition of fillK_ __________________________________ Do you Yahoo!? All your favorites on one personal page � Try My Yahoo! http://my.yahoo.com

1 0

coercion to Int
by lothar 31 Dec '04

31 Dec '04

what coercion can i use to get the below program to compile? i see class (Real a, Fractional a) => RealFrac a where round :: (Integral b) => a -> b and class (Fractional a) => Floating a where sqrt :: a -> a fillK_ :: Int -> Int fillK_ x = round (sqrt x) -- line 2 Hugs session for: H:\Program Files\Hugs98\lib\Prelude.hs Prelude> :load xva Reading file "xva.hs": Type checking ERROR "xva.hs":2 - Instances of (RealFrac Int, Floating Int) required for definition of fillK_

1 0

Utility functions
by Mark Carroll 31 Dec '04

31 Dec '04

I find myself writing things like, splitListOn :: Eq a => a -> [a] -> [[a]] splitListOn delimiter = unfoldr splitter . (delimiter :) where splitter [] = Nothing splitter xs = Just (span (/= delimiter) (tail xs)) This is a sort of intersperse-opposite, in that... myId delimiter = concat . intersperse [delimiter] . splitListBy delimiter ...myId foo turns into a sort of id for lists of the correct type. With this, and other things, I always have a feeling that it's probably in the standard library somewhere but I didn't notice - maybe because it's abstracted out of recognition, just like "sequence" does Cartesian products for us, but not so that I noticed right away. Is there a good place to put these things - little things that feel like that maybe they're already in the standard library, and maybe they should be? I'd hate to be unknowingly reinventing the wheel all the time. I don't see an obviously-appropriate page for these on the Haskell Wiki, but maybe I missed it, or maybe I should create one. -- Mark

4 7

RE: Haskell Pangolins
by Dominic Fox 30 Dec '04

30 Dec '04

The use of elem is certainly more concise. But this isn't quite right (Hugs rejects it): > isYes = `elem` ["y", "yes", "Y", "YES"] I think what's meant is: isYes = flip elem ["y", "yes", "Y", "YES"] and agree that isYes = flip elem ["y", "yes"] . (map toLower) is even better. > Of course, the very last "if" could be, > > if isYes playAgain > then play rewrittenNode > else putStr "Goodbye for now." I had it the other way around because of a vague notion about tail-recursion that perhaps doesn't apply here? It's useful to know where "do"s and parentheses are not needed. I agree about records; I thought they would be useful, and ended up not using them. Derek's use of LiftM is new to me, as most things in Haskell are. The @ operator (fullstring@(c:cs)) looks very handy. Thanks to all, Dominic

1 0

Re: dummy variables
by Serge D. Mechveliani 30 Dec '04

30 Dec '04

What I meant: is this reasonable for future Haskell to make a variable _foo equivalent to `_' ? In this case, one can use _foo as a self-commenting dummy variable: let (x, _newEqs, _newVars) = f a (y, _newEqs, newVars ) = f b in x:y:newVars These _foo help to recall the type of f (suppose f is in another file, so that one needs to search and recall). This makes it easier to read/understand the program. ----------------- Serge Mechveliani mechvel(a)botik.ru On Wed, Dec 29, 2004 at 06:17:30PM +0000, Keean Schupke wrote: > Except for GHC, where a variable staring with an '_' will not report a > warning > if it is unused in the body of a funtion: > > let _ = x in y -- no warning > let result = x in y -- waring about result being unused > let _result = x in y -- no warning, but variable can still be used. > > Keean. > > Duncan Coutts wrote: > > >In message <20041229115341.A431(a)botik.ru> "Serge D. Mechveliani" > ><mechvel(a)botik.ru> writes: > > > > > >>Dear Haskellers, dear GHC team, > >> > >>Is a variable `_x' equivalent to `_' > >> > >> > > > >No, '_x' is a perfectly ordinary variable. The only special "dummy variable" (a > >pattern that matches anything but does not bind a varialbe) is '_'. > > > > > > > >>Does really Haskell mean this? It this reasonable? > >>How to set self-commenting dummy variables? > >> > >> > > > >You can use them as dummy variables by never using them in an expression > >context, only in pattern/binding context. As you noted they should be unique > >withing each scope. > > > >Duncan > >_______________________________________________ > >Glasgow-haskell-users mailing list > >Glasgow-haskell-users(a)haskell.org > >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > >

1 0

Haskell Pangolins
by Derek Elkins 30 Dec '04

30 Dec '04

I've rewritten it closer to the way I would have written it. Most of the changes are minor syntactic changes that you may or may not agree with. Probably the most confusing part of the original code was the declaration of the Node datatype as a (sum of) record(s), then the subsequent ignoring of the fact that it is a record. In my experience, most Haskell programmer's would not (for better or worse) use a record in this case. The comments I've added are with regards to the original source code; compare this version and yours to see the differences. As far as how the code actually works, it seems to be the most natural implementation. -- Pangolins in Haskell -- A simple animal guessing game module Main ( main ) where import Control.Monad ( liftM ) -- declared as record, but not used as record data Node = Guess String | Question String Node Node -- putStrLn s == putStr s >> putStr "\n" ask question = do putStrLn question getLine -- m >>= return == m (one of the monad laws) isYes "y" = True isYes "yes" = True isYes "Y" = True isYes "YES" = True isYes _ = False withArticle fullstring@(c:cs) | c `elem` "aeiou" = "an " ++ fullstring | otherwise = "a" ++ fullstring rewrite (Guess name) = do reply <- ask ("Is it " ++ withArticle name ++ "?") -- superfluous parens if isYes reply -- superfluous parens then do putStr "Computer wins!\n" return (Guess name) else do newName <- ask "What is it, then?" newQuestion <- newQuestion name newName return newQuestion rewrite (Question text ifYes ifNo) = do reply <- ask text if isYes reply then liftM (flip (Question text) ifNo) (rewrite ifYes) else liftM (Question text ifYes) (rewrite ifNo) newQuestion a1 a2 = do -- superfluous parens text <- ask ("Tell me a question that can be used to distinguish between " ++ withArticle a1 ++ " and " ++ withArticle a2 ++ ".") answer <- ask ("What would the answer to your question be if it was " ++ withArticle a1 ++ "?") if isYes answer -- superfluous parens then return (Question text (Guess a1) (Guess a2)) else return (Question text (Guess a2) (Guess a1)) -- superfluous parens duck = Guess "duck" dog = Guess "dog" initialNode = Question "Does it quack?" duck dog -- superfluous 'do' main = play initialNode play :: Node -> IO () play node = do rewrittenNode <- rewrite node playAgain <- ask "Play again?" if not (isYes playAgain) then putStrLn "Goodbye for now." -- superfluous 'do' else play rewrittenNode -- superfluous 'do'

1 0

GUI
by Matthew Roberts 30 Dec '04

30 Dec '04

I know this question is probably going over old ground - so I apologise in advance. However, I want to know if there has been any practical standardisation in the GUI area. Last time I looked at this it seemed some decisions had been made (bind to existing api - wxWindows?). I am waiting for some real standardisation and a mature API before I jump ship from Java for my day-to-day programming. Has there been any progress? Matt

6 6

Named function fields vs. type classes
by John Goerzen 30 Dec '04

30 Dec '04

Hi, I often have a situation where I'm designing specialized components to do a more general task. Examples could include mail folder code (maildir, mbox, etc), configuration file parsing, protocol handlers for URL accesses, logging backends, etc. For some of these, I've used a data object with named fields, each one of them being a function that performs various tasks (open connection to the URL, read data, whatever.) So, I get a standard interface. The advantage of this approach is that I can build a list containing all sorts of different data objects in it. For others, I've used typeclasses, and made the different specialized components a member of the typeclass. This seems to provide a cleaner interface, and one that is more readily extended (maybe I want to support IMAP folders, and support all its searching capabilities too). On the other hand, it's difficult or impossible to make a list of a bunch of different types of things that have nothing in common save being members of the class. Is there any advice on the best way to do these things? Thanks, John

5 5

safe code to run in finalizers: ACIO revisited
by Robert Dockins 30 Dec '04

30 Dec '04

Due to one of the threads on cafe recently, I have been doing some thinking about finalizers. There is this sort of intuitive notion that some things shouldn't be done inside finalizers. For example, no output should be produced, because the output handles may have been finalized already, and finalizers can't be ordered. So, to be safe, the action of a finalizer must commute with every other finalizer (they must be central). And because the finalizers might not be run (compiler can't provide guarantees), their result should not be directly observable, and if the finalizer is not run, the program should still be correct (they must be affine). So a separate ACIO monad for affine central IO actions would be the appropriate context for finalizers. The orignial ACIO proposal was presented in the context of module initalization. http://www.haskell.org//pipermail/haskell-cafe/2004-November/007664.html It strikes me that "module init time" and "finalizer time" are very similar execution contexts. They are 1) outside the normal program flow 2) mostly intended to make the bookeeping work out 3) non-deterministic wrt when/if they will be run 4) if used in the "wrong" ways, they can break program safety. 5) they both are viewed with disfavor for the bad things people can do with them I'm not sure where I am going with this observation, but it seems that if some solution (such as an ACIO monad) could make both of these kinds of action safe, it would probably be worth a second thought.

3 4