January 2006 - Haskell-Cafe

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 02 Jan '06

02 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 01 Jan '06

01 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