- Haskell-Cafe - Haskell.org

Sequencing Operations in a Monad
by Dominic Steinitz 15 Sep '07

15 Sep '07

> If you arrange the types to try to do all the operations inside the IO > monad you can't chain together more than 1 binary operation. eg. > > do > S <- A + B > Z <- Q * S > > vs > > do > S <- Q * (A + B) > > Are there any suggestions for this dilemma? Am I using the wrong monad for > this task? I'm not sure if this is what you are asking but isn't liftM2 or some variant what you need? Dominic.

3 2

haskell on llvm?
by brad clawsie 15 Sep '07

15 Sep '07

has anyone ever considered using llvm as a infrastructure for haskell compilation? it wold seem people are looking at building frontends for scheme, ocaml, etc. i don't know if an alternate backend is appropriate, but it would seem to be an interesting way to aggregate the best thinking for various optimizations over a more diverse group of developers.

4 4

Is "take" behaving correctly?
by PR Stanley 15 Sep '07

15 Sep '07

Hi take 1000 [1..3] still yields [1,2,3] I thought it was supposed to return an error. Any ideas? Thanks, Paul

32 58

Memory leak or wrong use of Array ?
by L.Guo 15 Sep '07

15 Sep '07

Hi MailList Haskell-Cafe: I am tring to solve Project Euler problem 70. And write some code. (will at the end of this mail) And, I run the code in GHCi. The problem is that, when the input is 1,000,000, it works fine, when the input is up to 10,000,000, the memory GHCi used increase very fast and did not stop. Is this a memory leak ? or, is there some mis-understand about array ? Regards -------------- -- Mudules : import Data.Array.IO import Foreign ( unsafePerformIO ) -- Codes : p070_solve = putStrLn . show $ solutionOf 10000000 where isPerm a b = sort (show a) == sort (show b) phis n = unsafePerformIO $ do arr <- newArray (2,n) (False,1/1) :: Fractional t => IO (IOArray Int (Bool,t)) mapM_ (sieve arr n) [2..n] factors <- getElems arr return . map (\(n,(b,f)) -> (n,floor $ toRational n*f)) $ zip [2..n] factors where sieve arr ubound p = do (b,o) <- readArray arr p if b then return () else mapM_ (update arr (toRational p)) . takeWhile (<=ubound) $ iterate (+p) p update arr p i = do (_,o) <- readArray arr i writeArray arr i (True,o*(p-1)/p) solutionOf = snd . minimum . map (\(n,phi)->(toRational n / toRational phi,n)) . filter (uncurry isPerm) . phis -------------- L.Guo 2007-09-14

3 3

ANN: HPDF 1.1
by alpheccar 14 Sep '07

14 Sep '07

I have just released the version 1.1 of HPDF. You can get it on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HPDF-1.1 In this release, I am experimenting with typesetting. -- Christophe.

1 0

Clarification Please
by PR Stanley 14 Sep '07

14 Sep '07

Hi Taken from chapter 6, section 8 of the Hutton book on programming in Haskell: 5. Using merge, define a recursive function msort :: (Ord a) => [a] -> [a] that implements merge sort, in which the empty list and singleton lists are already sorted, and any other list is sorted by merging together the two lists that result from sorting the two halves of the list separately. : Hint: first define a function ¬halve :: [a] -> [([a], [a])] ¬that splits a list into two halves whose length differs by at most one. Create a halve function - okay, that's fairly straightforward. The rest, I'm afraid, is a little obscure. I'm not looking for the solution; I'd like to work that out for meself. However, I'd really appreciate some clues as to the general structure of the algorithm. Much obliged, Paul

4 5

getting crazy with character encoding
by Andrea Rossato 14 Sep '07

14 Sep '07

Hi, supposed that, in a Linux system, in an utf-8 locale, you create a file with non ascii characters. For instance: touch abèèè Now, I would expect that the output of a shell command such as "ls ab*" would be a string/list of 5 chars. Instead I find it to be a list of 8 chars...;-) That is to say, each non ascii character is read as 2 characters, as if the string were an ISO-8859-1 string - the string is actually treated as an ISO-8859-1 string. But when I print it, now it is displayed correctly. I don't understand what's wrong and, this is worse, I don't understand what I should be studying to understand what I'm doing wrong. After reading about character encoding, the way the linux kernel manages file names, I would expect that a file name set in an utf-8 locale should be read by locale aware application as an utf-8 string, and each character a unicode code point which can be represented by a Haskell char. What's wrong with that? Thanks for your kind attention. Andrea Here the code to test my problem. Before creating the file remember to set the LANG environmental variable. Something like: export LANG="en_US.utf8" should be fine. (Check your available locales with "locale -a") import System.Process import System.IO import Control.Monad main = do l <- fmap lines $ runProcessWithInput "/bin/bash" [] "ls ab*" putStrLn (show l) mapM_ putStrLn l mapM_ (putStrLn . show . length) l runProcessWithInput cmd args input = do (pin, pout, perr, ph) <- runInteractiveProcess cmd args Nothing Nothing hPutStr pin input hClose pin output <- hGetContents pout when (output==output) $ return () hClose pout hClose perr waitForProcess ph return output

14 24

MonadGL - Partitioning effects without giving up type inference
by Jules Bean 14 Sep '07

14 Sep '07

The OpenGL bindings which come bundled with ghc are a really great example of how even an "almost-literal" port of a C API can still be easier to work with in haskell than it is in C, because of the benefits of type inference and powerful abstractions. Even the ability to mapM_ is a tool to make C programmers envious, and there are useful combinators like preservingMatrix to guarantee pairing of pushes and pops. Because the bindings are ported over using the FFI, all the GL calls are in the IO monad. GL is build around state machines, so it's not at all surprising to end up in some kind of state monad. However, we find that the type system is not powerful enough to distinguish between myActionWhichOnlyMakesGLCalls :: IO () and myActionWhichMixesGLAndIO :: IO () It would be much nicer if the type-system could distinguish the two. One case in point is that an arbitrary IO action can modify IORefs, and it would be nice to have actions whose type guaranteed that they didn't do that. It's fairly simple to imagine something like the following: > {-# OPTIONS -fglasgow-exts #-} (extensions are only for deriving (Monad), it's not important) > > newtype GL a = GL { runGL :: IO a } deriving (Monad) > > unsafeIOToGL :: IO a -> GL a > unsafeIOToGL = GL The intention here of course is that we export 'runGL' which is safe, having type GL a -> IO a, but don't export unsafeIOToGL. Then we have lots of functions which are imported via the FFI and end up with IO types, here is a trival example: > _foo :: IO () > _foo = putStrLn "OpenGL!" And we embed them into the GL monad. No other module can corrupt our GL monad because we don't export unsafeIOToGL. > foo :: GL () > foo = unsafeIOToGL _foo As far as it goes, this technique is absolutely fine. We end up being able to write actions entirely in the GL monad: *Main> :t do { foo ; foo ; foo } do { foo ; foo ; foo } :: GL () ...as well as actions which mix general IO and GL calls : *Main> :t do { runGL foo ; putStrLn "Not a GL call" ; runGL foo } do { runGL foo ; putStrLn "Not a GL call" ; runGL foo } :: IO () The point of this message is actually to get rid of those annoying 'runGL' calls. When writing an IO action I want to be able to freely intermix IO and GL calls. When writing a GL-only action, I want to only use GL calls. And I want the type system to enforce that; and ideally, infer it too. So we define a type-class for "monad which can perform GL" : > class Monad m => MonadGL m where > runMonadGL :: m a -> IO a > embedGL :: GL a -> m a And we write an instance for IO: > instance MonadGL IO where > runMonadGL = id > embedGL = runGL Now we are able to bind our FFI call _foo slightly differently: > foo' :: MonadGL m => m () > foo' = embedGL foo This is interesting because, although we know that IO is in fact the only instance of MonadGL, there might in principle be others. (For example, GL is itself an instance of MonadGL if you put runMonadGL = runGL and embedGL = id). The type signature for foo' guarantees that it will run in *any* MonadGL, and therefore can't use any IO-specific effects, only the GL ones. Now we get the automatic type inference we want: *Main> :t do { foo' ; foo' ; foo' } do { foo' ; foo' ; foo' } :: (MonadGL t) => t () This only performs GL actions, no IO. *Main> :t do { foo' ; putStrLn "Normal" ; foo' } do { foo' ; putStrLn "Normal" ; foo' } :: IO () The single IO call here forces the type to IO, but we are not required to put noisy 'runGL's in front of every GL call. This technique is quite scalable in that you can have any number of MonadFoos representing different librarys with different kinds of state, and (as long as you don't mind the modest blow-up in type signature size) you get, for an arbitrary action, a type signature which pins down precisely what kinds of side-effect the action can have. It would, however, be a real pain to run through all the 'foreign' calls in the rather large GL library and add appropriate wrappers of the form 'embedGL . unsafeIOToGL'. Definitely a job for an automated tool. Incidentally, I don't believe this technique has any performance implication at all. The newtypes are all erased at compile time. Any comments? I'm sure this has been shown before but I don't remember where. Jules

3 2

Vital for real Haskell?
by Peter Verswyvelen 14 Sep '07

14 Sep '07

I showed Vital (http://www.cs.kent.ac.uk/projects/vital) to some teachers at my university and they where really enthousiastic. IMHO the Haskell community needs something like this, but for *real* Haskell (preferable with extensions), and not using Java... Is any work being done on something like this? Thanks, Peter

2 1

haskell and reflection
by Greg Meredith 14 Sep '07

14 Sep '07

Haskellians, Am i wrong in my assessment that the vast majority of reflective machinery is missing from Haskell? Specifically, - there is no runtime representation of type available for programmatic representation - there is no runtime representation of the type-inferencing or checking machinery - there is no runtime representation of the evaluation machinery - there is no runtime representation of the lexical or parsing machinery Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740 http://biosimilarity.blogspot.com

5 6