- Haskell-Cafe - Haskell.org

ST monad
by oleg＠pobox.com 03 Jan '06

03 Jan '06

Bulat Ziganshin wrote: the following code can't go through typechecking > import Control.Monad.ST > import Data.Array.ST > main = print $ runST $ > do arr <- newArray (1,10) 127 > a <- readArray arr 1 > writeArray arr 1 216 > b <- readArray arr 1 > return (a,b) Indeed. The short answer: use runST (long expression) rather than runST $ long expression when it comes to higher-ranked functions such as runST. A longer answer: http://www.haskell.org/pipermail/haskell-cafe/2004-December/008062.html > let me know what i need to read to fix it myself MLF (see Daan Leijen, A. Loeh, `Qualified types for MLF', ICFP05)

1 0

ST monad
by Bulat Ziganshin 03 Jan '06

03 Jan '06

Hello the following code can't go through typechecking. can anyone help me to fix it or, better, let me know what i need to read to fix it myself? :) import Control.Monad.ST import Data.Array.ST main = print $ runST $ do arr <- newArray (1,10) 127 a <- readArray arr 1 writeArray arr 1 216 b <- readArray arr 1 return (a,b) PS: error message is b.hs:4:15: Inferred type is less polymorphic than expected Quantified type variable `s' escapes Expected type: ST s a -> b Inferred type: (forall s1. ST s1 a) -> a In the first argument of `($)', namely `runST' In the second argument of `($)', namely `runST $ (do arr <- newArray (1, 10) 127 a <- readArray arr 1 writeArray arr 1 216 b <- readArray arr 1 return (a, b))' -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

Catching string from error function with GHC Control.Exception
by Andrew Savige 03 Jan '06

03 Jan '06

I am a Haskell beginner, using GHC 6.4.1. Suppose I have a function, tt, say, which may call error. For the purposes of testing tt, I'd like to be able to catch the error string and assert that it matches the expected error string. Is HUnit or QuickCheck (or either) the appropriate tool for this sort of testing? I managed to get it working with HUnit, but it's horribly kludgy mainly because I'm yet to grok monads. The little test program below demonstrates my question outside of HUnit: import Control.Exception tt :: String -> Int tt s = error ("hi error '" ++ s ++ "'") -- tt s = read s ttWrap :: String -> IO String ttWrap x = do let r = tt x -- comment out next line, error string not caught putStr (show r) return (show r) ttWrap2 :: IO String ttWrap2 = do res <- tryJust errorCalls (ttWrap "123") case res of Right r -> return (show r) Left r -> return r main = do x <- ttWrap2 putStrLn ("caught:" ++ x) y <- ttWrap2 putStrLn ("caught:" ++ y) When you run the above test program, it does indeed catch the error string thrown by the tt function (and prints it out in main). However, if you comment out the putStr line as shown in the comment above, it no longer catches the error string, but dies instead. Why? I'm sure there is a cleaner way to achieve what I'm trying to do and I'd appreciate advice on the best way to do this. Thanks, /-\ Send instant messages to your online friends http://au.messenger.yahoo.com

3 2

Re: Haskell Speed
by Brent Fulgham 03 Jan '06

03 Jan '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I recently stumbled across this thread, related to the Shootout > (which I run) and wanted to add a few comments. > > First, I agree that I am a Haskell novice; however, I rely on > people like yourselves to show me where I am doing things wrong. > If our solutions are horribly inefficient, please tell us what we > can do to resolve the problem. But note that in some cases, we are > purposely being inefficient so that we can measure the cost of > certain basic operations. > > Doug Bagely started the Shootout as a comparison of scripting > languages. After I revived it, I started focussing more on > functional and logic languages, since I was curious how these > languages would fare in comparison with the more typically-used > languages like C/C++. Consequently, many of the tests show this > heritage and are highly imperative. We have been working to relax > some of these rules, and have added many new tests that try to be > more amenable to comparison of lazy and 'strict' languages. > > In our defense I would like to plead that it is not easy to devise > short problems (e.g., that can be expressed in a page or so of code > - -- we try to limit it to 100 lines of C++ code as a rough > benchmark), and that also take enough run time for a meaningful > measurement. So, many of the tests initially suffered from foolish > looping and repetition as a means of extending the run times > sufficiently to allow measurement. We have been changing tests so > that fewer of them rely on these kinds of activities to generate > results. We are always interested in new ideas, and would consider > any benchmark ideas you have. > > Finally, I don't agree at all that Haskell's scores show poorly. > The GHC compiler is one of the better performers, and regularly > trounces other languages when we let it do its job. For example, > we had to jump through many hoops to convince the compiler to > actually invoke all the loops required to do the "same way" tests > on methodcall and similar benchmarks, because the compiler was so > sharp at identifying wasted effort and optimizing it away. Perhaps > we don't say this strongly enough on the site, but I was truly > impressed at its ability to toss aside wasted calculations and > focus on the core problem. I'll admit it was frustrating because > we wanted to see how long it would take for Haskell to make N > recursive calls, or what have you, but the fact that the compiler > saw that there was no need to do the recursion to get the result is > quite amazing! I'm sure this would be extremely useful when > compiling real-world programs. > > There have been many cases where the "obvious" solution in Haskell > is a great performer, but we discover that it's so fast because it > has tossed aside wasted cycles and just done the work necessary to > arrive at a solution. It's unfortunate, since we then have to > dirty the program with wasted steps to force it to exercise the > tasks required. But in a "real world" test I think Haskell would > show quite well. > > As we evolve into the newer tests, I think you will see Haskell > make a better showing. Simon Marlow (and others) have been a huge > help in optimizing the existing tests in a "fair" fashion, and as > we provide more "same thing" type tests, I think Haskell will pull > further ahead. > > Thanks, > > - -Brent > > P.S. I must say that I find Haskell to be the most esthetically > pleasing language -- it's quite beautiful when printed! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDuWIlzGDdrzfvUpURAnJuAJ90G9ltXH5m+jsz6D0QoucoY6anNACfcfkQ Mg2K0NO0kbBYLy4ZX7LCoeM= =uGnw -----END PGP SIGNATURE-----

1 0

Typechecking Help
by Dominic Steinitz 02 Jan '06

02 Jan '06

I have a function which, without a type annotation, types as: *Codec.ASN1.BER> :t choiceAux choiceAux :: forall (m :: * -> *) e e1. (MonadState [Maybe Encoding] m, MonadState [Maybe Encoding] (StateT [Maybe Encoding] m), MonadError e (StateT [Maybe Encoding] m), MonadError e1 m) => (TagPlicity, NamedType) -> Encoding -> m Defaulted But if I try to give it a type annotation of choiceAux :: (MonadState [Maybe Encoding] m, MonadState [Maybe Encoding] (StateT [Maybe Encoding] m), MonadError e (StateT [Maybe Encoding] m), MonadError e1 m) => (TagPlicity, NamedType) -> Encoding -> m Defaulted I get Codec/ASN1/BER.hs:66:0: Quantified type variable `e1' is unified with another quantified type variable e When trying to generalise the type inferred for `choiceAux' Signature type: forall (m :: * -> *) e e1. (MonadState [Maybe Encoding] m, MonadState [Maybe Encoding] (StateT [Maybe Encoding] m), MonadError e (StateT [Maybe Encoding] m), MonadError e1 m) => (TagPlicity, NamedType) -> Encoding -> m Defaulted Type to generalise: (TagPlicity, NamedType) -> Encoding -> m Defaulted In the type signature for `choiceAux' When generalising the type(s) for tc, choiceAux, k Changing e1 to e makes it typecheck. 1. Can anyone explain why the typechecker rejects the type it had inferred for itself? 2. I thought StateT guaranteed that the lifted monad was a state monad so why is the typechecker adding MonadState ... (StateT ... ) to the list of constraints? Ditto for MonadError ... (StateT ... )? Thanks, Dominic. PS What I thought I was going to get was choiceAux :: forall (m :: * -> *) e. (MonadError e m, MonadState [Maybe Encoding] m) => (TagPlicity, NamedType) -> Encoding -> m Defaulted and this is what I have now specified.

3 4

Bug in "Haskell for C programmers" tutorial?
by Erik de Castro Lopo 02 Jan '06

02 Jan '06

Hi all, I'm working through the "Haskell for C programmers" tutorial and in this section": http://www.haskell.org/~pairwise/intro/section2.html#part3 it has: fib :: Num a, Num b => a -> b fib n = fibGen 0 1 n fibGen :: Num a, Num b => b -> b -> a -> b fibGen a b n = case n of 0 -> a n -> fibGen b (a + b) (n - 1) which doesn't work with GHC, but it does if I add parentheses around both instances of "Num a, Num b". Is this a bug in the tutorial or is there another explanation? Cheers, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin." - John Von Neumann (1951)

4 11

Project postmortem II /Haskell vs. Erlang/
by Dominic Steinitz 02 Jan '06

02 Jan '06

I'd like to second Joel's comments on records very strongly. In an application where you need lots of big records (such as supporting X.509), you end up with very unnatural names for components. It works but it's not pretty. Dominic.

1 0

(no subject)
by Henk-Jan van Tuyl 02 Jan '06

02 Jan '06

L.S., I used the link checker of the World Wide Web Consortium to check the links on haskell.org; there are several links broken. As the checks take a long time, I have put the results on my website: http://members.chello.nl/hjgtuyl/computing/Haskell/checklinks/checklink.htm The check is a recursive check with depth 3, starting from the home page; this will probably not cover all of the website. To repeat this check, go to: http://validator.w3.org/checklink -- Best wishes for the new year, Henk-Jan van Tuyl -- http://members.chello.nl/hjgtuyl -- Using Opera's revolutionary e-mail client: https://secure.bmtmicro.com/opera/buy-opera.html?AID=789433

1 0

expanding do notation / StateMonad example from tutorial all about monads
by Marc Weber 01 Jan '06

01 Jan '06

Hi.. I'm still struggling with monads ;-) In the tutorial "All about monads" there is the function getOne used: getOne:: (Random a) => (a,a) -> State StdGen a getOne bound = do g <-get (x,g')= return $ randomR bounds g put g' return x In the haskell "Yet another Haskell tutorial" by Hal Daume it is said that do {fp <- e; es} is translated to: let ok p = do {es} ; ok _ = fail "..." in e >>= ok Using this rule I was able to expand the first "<-" of getOne: getOne2 :: (Random a) => (a,a) -> State StdGen a getOne2 bounds = let ok g = do (x,g') <- return $ randomR bounds g put g' return x ok _ = fail "asd" in get >>= ok but I couldn't manage to also expand the second. My attempt is: getOne3 :: (Random a) => (a,a) -> State StdGen a getOne3 bounds = let ok g = do let ok2 (x,g') = do { put g'; return x } -- ok2 _ = fail "2" in (return $ randomR bounds g >>= ok2 ok _ = fail "1" in get >>= ok But I get this compile error in at the line marked by a trailing --: "The last statement in a 'do' construct must be an expression" Can you help me? Sincerly Marc

2 1

OpenAL bindings / compiling ghc 6.5
by Michael Benfield 01 Jan '06

01 Jan '06

I see here: http://www.haskell.org/HOpenGL/newAPI/ OpenAL bindings listed as part of the Hierachical Libraries. And when I download the source to a development snapshot of GHC, there they are. Is there a way to install this on GHC 6.4? Alternatively... I can't get GHC 6.5 to compile. I do ./configure && make and it gets to this step: ------------------------------------------------------------------------ ==fptools== make all -r; in /Users/mike/source/ghc-6.5.20051221/ghc/compiler ------------------------------------------------------------------------ and sits forever (well, I only let it sit a day and a half, actually...). And the only relevant process that seems to be running is gmake (no ghc or gcc or anything). I've tried a few different versions of 6.5, including HEAD and STABLE branch. I'm on Mac OS 10.3.9. Thanks. Mike Benfield

4 7