December 2008 - Haskell-Cafe

Re: [Haskell-cafe] Re: Time for a new logo?
by Jeff Wheeler 17 Dec '08

17 Dec '08

On Dec 16, 2008, at 10:08 PM, Ryan Grant wrote: > nice. > the first is better. > in the second, i don't even see the lambda. Thanks the feedback. I just uploaded a new version [1] that is icon- sized, although the font used is Helvetica Neue, which is non-free. I have no free fonts on my Mac, unfortunately, so it'll stay for the moment. Jeff Wheeler [1] http://media.nokrev.com/junk/haskell-logos/logo4.png

2 1

Please tell me this function exists
by Brian Hurt 17 Dec '08

17 Dec '08

I know it's not hard to write, but still: concat :: String -> [String] -> String concat _ [] = "" concat _ [x] = x concat sep x:xs = x ++ sep ++ (concat sep xs) I've got to be stupid and missing it in the standard libraries. Please tell me where. Thanks. Brian

5 6

monadic versus aplicative style. These two snips seem to do the same thing yet one has a bug.
by Thomas Hartman 17 Dec '08

17 Dec '08

Hi, I rewrote a piece of code that used applicative to use instead monadic style, basically because I wanted to adapt it for my own purposes but hadn't wrapped my head around applicative yet. Unfortunately my rewrite had a bug, which I'm still not completely clear on. (I am guessing it's a laziness mixed with IO issue.) I discarded my own version and am using the original now of course, but I'm curious if anyone has anything to say on the difference between these two bits of code and, in general if there is any way to "think" about the difference between monadic and applicative. For what it's worth, the code comes from HSTringTemplate (on hackage). The bug is described in http://groups.google.com/group/HAppS/browse_thread/thread/70d4b1fbe8a4c7ac Basically, in happs, this bit of code caused an unrelated handler to not fully pages correctly, where there was more than one image to load. It took forever to diagnose and track this down. Ugh. Thanks, thomas. -- incorrect behavior directoryGroup' :: (FilePath -> FilePath -> IO (StringTemplate a)) -> FilePath -> IO (STGroup a) directoryGroup' templatereader path = do fs <- return . ( filter ((".st" ==) . takeExtension) ) =<< getDirectoryContents path templates <- mapM (templatereader path) fs stmapping <- return $ zip fs templates return $ groupStringTemplates stmapping -- correct behavior --directoryGroup2' :: (Stringable a) => FilePath -> IO (STGroup a) directoryGroup'2 templatereader path = groupStringTemplates <$> (fmap <$> zip . (map dropExtension) <*> mapM ( templatereader path ) =<< filter ((".st" ==) . takeExtension) <$> getDirectoryContents path)

1 2

Threads not running under GHC 6.10?
by Gwern Branwen 17 Dec '08

17 Dec '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So, the Hint library was recently updated and I was editing Mueval to run with (i386) 6.10, when I discovered that for some reason, DoS'ing expressions were succeeding in rendering my machine unusable. Eventually, I discovered that my watchdog thread didn't seem to be running. But with +RTS -N2 -RTS all my tests did pass! Here's a simple example of what I mean; the following is basically a very lightly adapted version of the actual Mueval code: - ---------------- import Control.Concurrent (forkIO, killThread, myThreadId, threadDelay, throwTo, yield, ThreadId) import System.Posix.Signals (sigXCPU, installHandler, Handler(CatchOnce)) import Control.OldException (Exception(ErrorCall)) main :: IO () main = do tid ThreadId -> IO () watchDog tout tid = do installHandler sigXCPU (CatchOnce $ throwTo tid $ ErrorCall "Time limit exceeded.") Nothing forkIO $ do threadDelay (tout * 100000) -- Time's up. It's a good day to die. throwTo tid (ErrorCall "Time limit exceeded") yield -- give the other thread a chance killThread tid -- Die now, srsly. error "Time expired" return () -- Never reached. Either we error out in -- watchDog, or the evaluation thread finishes. - -------------- Now, from the looks of it, this should always error out with "Time limit exceeded." And the threading is done via forkIO, so it shouldn't matter how it's compiled (be it threaded or no) or run; nor do we need to worry about optimizations, since x has no sensible value for any input - it's always bottom. But the results are very different: gwern@craft:31542~>=ghc -fforce-recomp -O0 example.hs && ./a.out ^C^C gwern@craft:31532~>=ghc -fforce-recomp -O0 -threaded example.hs && ./a.out ^C^C gwern@craft:31536~>=ghc -threaded -fforce-recomp -O0 -threaded example.hs && ./a.out +RTS -N1 -RTS [a minute later] ^C^C^C^C^C^C gwern@craft:31540~>=ghc -threaded -fforce-recomp -O0 -threaded example.hs && ./a.out +RTS -N2 -RTS a.out: Time limit exceeded gwern@craft:31543~>=ghc -fforce-recomp -O2 example.hs && ./a.out a.out: Time limit exceeded gwern@craft:31544~>=ghc -threaded -fforce-recomp -O2 example.hs && ./a.out a.out: Time limit exceeded gwern@craft:31545~>=ghc -threaded -fforce-recomp -O2 example.hs && ./a.out +RTS -N1 -RTS a.out: Time limit exceeded gwern@craft:31546~>=ghc -threaded -fforce-recomp -O2 example.hs && ./a.out +RTS -N2 -RTS a.out: Time limit exceeded So it seems that without optimizations, or without explicit/multiple OS threads, the watchdog thread never gets called! I'm not any sort of expert on parallelism or GHC, but this seems like a bad thing to me. One final note: I suspect there are further ways this can manifest. When compiled with -O2, example.hs terminates (as it should). But Mueval does in fact set -O2 as a ghc-option:, and yet I still found it looping. So, does anyone know whether this is an already known bug or whether it's something else? - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkk63+EACgkQvpDo5Pfl1oITZgCdG2p4VcB6m5IhfqzOT0fi5qrI VagAnRILZSxBzadSj2wlzoOWfBuwdbJo =X61b -----END PGP SIGNATURE-----

3 4

Type wildcards
by Eyal Lotem 17 Dec '08

17 Dec '08

Martin Foster (aka. EvilTerran) suggested an interesting idea, and I decided it was too nice to ignore/be forgotten inside Martin's head... So I'd like to try and suggest it. Type wildcards that allow partially specifying types, e.g: f :: _ -> String f x = show x This will instruct the type-inferrer to "fill out" the wild-card part only (e.g: Show a => a). This feature can be used for a couple of benefits: A. It allows hard-coding part of a type, rather than the all-or-nothing situation we have now (I want to force a single parameter to be more specific, but I'd still prefer to infer the whole type). B. Without scoped type variables, there are currently situations you cannot provide a type signature at all. This may mean that you cannot resolve type ambiguities in some cases, or make types more specific for some purpose. A type wild-card, in addition to scoped type variables, will allow to only specify the part we want. C. Its a nice way to kill the -Wall warnings about missing type declarations, if you want to: f :: _ f = "I am explicitly asking to infer this type, rather than specifying it" Eyal

4 3

Fwd: cabal-install sends invalid proxy password
by Valery V. Vorotyntsev 17 Dec '08

17 Dec '08

Hello, > I was surprised to discover that `cabal-install' -- a popular utility > for installing Hackage packages -- cannot work with HTTP proxies. > Despite all the necessary code linked in. > > `cabal update' command returns HTTP 407 (Proxy Authentication Required) > error. The problem is explained below and patches follow. See http://article.gmane.org/gmane.comp.lang.haskell.libraries/10420 No response so far. (I start to suspect that there is just one "proxied haskeller" subscribed to `libraries' and `cabal-dev' lists:) -- vvv

1 0

How to think about this? (profiling)
by Patrick Perry 16 Dec '08

16 Dec '08

I agree with everyone else who has said that the better solution is Lemmih's. It is simple, fast, and does not use much memory. On the other hand, here is a more faithful implementation of what you were trying to write. To use mutable arrays, you need to work in either the IO or the ST monad. The advantage of ST is the function "runST", which is roughly equivalent to "unsafePerformIO", but is much safer. I hope this helps, Patrick \begin{code} import Control.Monad import Control.Monad.ST import Data.Array.ST import System.Environment -- | Create an array for storing the results of foo 0 through foo n. -- Initialize foo 0, foo 1, and foo 2, but set all other values to -- 'missing'. newMemo :: Int -> ST s (STUArray s Int Int) newMemo n = do arr <- newArray (0,n) missing :: ST s (STUArray s Int Int) writeArray arr 0 0 writeArray arr 1 1 writeArray arr 2 2 return arr -- | Code to indicate a missing value in the memo array. missing :: Int missing = -1 -- | Compute the value of the function at @i@, using the memo-ed results -- in the array. fooWithMemo :: STUArray s Int Int -> Int -> ST s Int fooWithMemo arr i = do x <- readArray arr i if x /= missing then return x else do r <- liftM3 (\ a b c -> a + b + c) (fooWithMemo arr $ i - 1) (fooWithMemo arr $ i - 2) (fooWithMemo arr $ i - 3) writeArray arr i r return r foo :: Int -> Int foo n = runST $ do arr <- newMemo n fooWithMemo arr n main = do (n:_) <- liftM (map read) getArgs print $ foo n \end{code}

1 0

Reader monad, implicit parameters, or something else altogether?
by Bjorn Buckwalter 16 Dec '08

16 Dec '08

All, I have a growing amount of astrodynamics code that relies on various physical "constants". The problem with these so called "constants" are that they either aren't really constants or aren't well known. An example is the leap second table (see Data.Time.Clock.TAI). I'd like to be able to fetch current values of these constants at runtime and make them accessible to my astrodynamics functions by some means. To clarify, once initialized the constants will be considered constant for the remainder of the program. I'd store the constants in a data structure along the lines of: > data AstroData a = AstroData > { mu_Earth :: GravitationalParameter a > , leapSeconds :: LeapSecondTable > } I would like to know if there is any consensus on what is the best way to make such a data structure accessible in pure functions. Passing it explicitly would be a mess. It seems that two options are to use either a Reader monad or implicit parameters. Using a Reader monad is straight forward enough though it requires writing/converting code in/to monadic style and adds some clutter to the formulae. It seems implicit parameters could be cleaner but I've seen them referred to as everything from evil to "just what you need" and rendering the Reader monad obsolete... What do you people recommend? Thanks, Bjorn Buckwalter

5 7

Random language humour
by Andrew Coppin 16 Dec '08

16 Dec '08

http://www.aegisub.net/2008/12/if-programming-languages-were-religions.html Seems pretty accurate, actually...

1 0

How to think about this? (profiling)
by Magnus Therning 16 Dec '08

16 Dec '08

This behaviour by Haskell seems to go against my intuition, I'm sure I just need an update of my intuition ;-) I wanted to improve on the following little example code: foo :: Int -> Int foo 0 = 0 foo 1 = 1 foo 2 = 2 foo n = foo (n - 1) + foo (n - 2) + foo (n - 3) This is obviously going to run into problems for large values of `n` so I introduced a state to keep intermediate results in: foo :: Int -> State (UArray Int Int) Int foo 0 = return 0 foo 1 = return 1 foo 2 = return 2 foo n = do c <- get if (c ! n) /= -1 then return $ c ! n else do r <- liftM3 (\ a b c -> a + b + c) (foo $ n - 1) (foo $ n - 2) (foo $ n - 3) modify (\ s -> s // [(n, r)]) return r Then I added a convenience function and called it like this: createArray :: Int -> UArray Int Int createArray n = array (0, n) (zip [0..n] (repeat (-1))) main = do (n:_) <- liftM (map read) getArgs print $ evalState (foo n) (createArray n) Then I thought that this still looks pretty deeply recursive, but if I call the function for increasing values of `n` then I'll simply build up the state, sort of like doing a for-loop in an imperative language. I could then end it with a call to `foo n` and be done. I replaced `main` by: main = do (n:_) <- liftM (map read) getArgs print $ evalState (mapM_ foo [0..n] >> foo n) (createArray n) Then I started profiling and found out that the latter version both uses more memory and makes far more calls to `foo`. That's not what I expected! (I suspect there's something about laziness I'm missing.) Anyway, I ran it with `n=35` and got foo n : 202,048 bytes , foo entries 100 mapM_ foo [0..n] >> foo n : 236,312 , foo entries 135 + 1 How should I think about this in order to predict this behaviour in the future? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus Haskell is an even 'redder' pill than Lisp or Scheme. -- PaulPotts

8 10