- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
by John Lato 23 Aug '10

23 Aug '10

> > From: John Millikin <jmillikin(a)gmail.com> > > On Sat, Aug 21, 2010 at 15:35, Paulo Tanimoto <ptanimoto(a)gmail.com> wrote: > > Apologies if I'm asking you to repeat yourself, but I couldn't find > > the explanation. Â What was the reason why you went with IterateeM > > instead of IterateeMCPS? Â Simplicity? > > Iteratees are difficult enough to understand already -- requiring > prospective users to learn and understand CPS would just be another > roadblock. The CPS implementation is also slower -- I performed some > basic benchmarking of IterateeM.hs and IterateeMCPS.hs, and CPS is > only faster without optimizations. At -O, they are equal, and at -O2, > IterateeM is faster. Apologies if this discussion has already moved on; I'm just catching up on weekend email but wanted to respond to this directly. It's not necessary to understand CPS to use CPS-based iteratees. The CPS implementation generally simplifies the types and removes the necessity for special combinators like ($$) and (>>==), so I strongly suspect newcomers will find it easier to use than other variants (although unfortunately I can no longer say this from personal experience). It incorporates the best features of Oleg's two implementations in IterateeM.hs. The only drawback is the added thought overhead of CPS, but users need not be aware of this for the most part. For those who do want to have a thorough understanding of the implementation, I think that the CPS variant is usually more understandable than alternatives. The "take" family and stream converters (maps, convStream) are all simplified compared to alternative definitions. This isn't always true; enumPair is a counterexample. But I think it's helpful in many common cases, and enumPair is tricky in any implementation. It might be true that many programmers will find CPS difficult in the abstract (I certainly do), but when it occurs in a specific implementation the concepts are usually much more tractable. At least for iteratees, there's a very direct correspondence between the CPS-style and IterateeM-style, which greatly eases understanding. Also, while the IterateeM implementations may be faster for certain operations than CPS, they are also slower for others, sometimes significantly so. My tests (all with -O2, and various other compiler options tried) prior to switching to the CPS implementation showed that it is competitive with, if not being, the fastest implementation in all cases. Most importantly, I didn't find any comparatively slow operations, which wasn't true for either of the IterateeM implementations. I think that a CPS implementation of iteratees is the best of all current alternatives for ease of use, and possibly the best-performing implementation depending on exactly what operations are being performed. Even if it's not the absolute fastest, it should be close enough that the other benefits outweigh a performance gain. Cheers, John

2 2

Fast Integer Input
by 200901104＠daiict.ac.in 23 Aug '10

23 Aug '10

I need a function which has fast conversion from Bytestring to Integer. I am currently using this: import qualified Data.ByteString.Lazy.Char8 as BS readInteger :: BS.ByteString -> Integer readInteger x = case BS.readInteger x of Just (i,_) -> i Are there faster implementations? This function takes 1.8 seconds to convert 2000 integers of length 10^13000. I need it to be smaller that 0.5 sec. Is it possible?

3 3

Second Call for Copy: Monad.Reader Issue 17
by Brent Yorgey 23 Aug '10

23 Aug '10

Whether you're an established academic or have only just started learning Haskell, if you have something to say, please consider writing an article for The Monad.Reader! The submission deadline for Issue 17 is **Friday, October 1, 2010** That's little more than a month away! Get started on your article now! =) The Monad.Reader ~~~~~~~~~~~~~~~~ The Monad.Reader is a electronic magazine about all things Haskell. It is less formal than journal, but somehow more enduring than a wiki- page. There have been a wide variety of articles: exciting code fragments, intriguing puzzles, book reviews, tutorials, and even half-baked research ideas. Submission Details ~~~~~~~~~~~~~~~~~~ Get in touch with me if you intend to submit something -- the sooner you let me know what you're up to, the better. Please submit articles for the next issue to me by e-mail (byorgey at cis.upenn.edu) Articles should be written according to the guidelines available from http://themonadreader.wordpress.com/contributing/ Please submit your article in PDF, together with any source files you used. The sources will be released together with the magazine under a BSD license. If you would like to submit an article, but have trouble with LaTeX please let me know and we'll work something out.

1 0

empty .prof file
by Vo Minh Thu 23 Aug '10

23 Aug '10

Hi, I'd like to profile a GLUT application. After a run of the application with the +RTS -p flag, the .prof file is actually created but is always empty. Does someone have a clue of what's going on? Would it be related to my application calling GLUT's leaveMainLoop to exit? Thanks, Thu

1 1

Re: [Haskell-cafe] Fast Integer Input
by 200901104＠daiict.ac.in 23 Aug '10

23 Aug '10

>>Does the length of those numbers happen to be fixed? It they are all >>exactly 13000 decimals then it should be possible to create a more >>optimised parser. Well actually they can have any number of digits less than 13000. But the only post processing of the numbers is calculating the binary logarithm of the number. Does that help? >>It would also help if you could post a working example of your code >>and some test data somewhere so people can run it and test if for >>themselves. I have a slow Internet connection. So I will attach the script I used to generate the cases instead.(Note: It will take a few minutes to complete)

1 0

[Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
by John Millikin 23 Aug '10

23 Aug '10

Most of you have probably read Oleg's essays on using left-fold enumerators for incremental IO. In short, by encapsulating monadic left-folds in an "Iteratee" type, incremental pure processing is possible without using lazy IO. Sources to read: Oleg: Streams and Iteratees < http://okmij.org/ftp/Streams.html > Magnus Therning: Trying to work out iteratees < http://therning.org/magnus/archives/735 > cdsmith: Iteratees Step By Step (Part 1) < http://cdsmith.wordpress.com/2010/05/23/iteratees-step-by-step-part-1/ > John Millikin (me): Understanding Iteratees < http://ianen.org/articles/understanding-iteratees/ > Currently, the primary package for left-fold enumerators is John Lato's "iteratee". It is based on Oleg's original code, extended to support various forms of containers, platform-specific IO, and codecs for the WAV and TIFF formats. While I appreciate Mr. Lato's development of the package, I find it far too large, and its documentation too sparse, to effectively use. To correct this, I've written the "enumerator" package. It is also derived from Oleg's IterateeM.hs , but with a simplified API and significantly reduced dependency list. Hackage entry: http://hackage.haskell.org/package/enumerator Haddock docs: http://ianen.org/haskell/enumerator/api-docs/ Source code (literate PDF): http://ianen.org/haskell/enumerator/enumerator.pdf darcs get http://ianen.org/haskell/enumerator/ Additionally, I've included examples of using enumerators to implement simplified versions of the "cat" and "wc" utilities. These should serve as a useful starting point for anybody who wants to use enumerators in their own code: http://patch-tag.com/r/jmillikin/enumerator/snapshot/current/content/pretty… http://patch-tag.com/r/jmillikin/enumerator/snapshot/current/content/pretty… There are already a few libraries using the existing "iteratee" package (snap, attoparsec-iteratee, hexpat-iteratee); I am very interested in advice from the authors of these libraries. In particular, are any of the removed features (ListLike, WrappedByteString, seeking) something your libraries depend on? Are there any useful combinators you'd like to see included?

14 50

Re: [Haskell-cafe] ANNOUNCE: Sifflet visual programming language, release 1.0!
by Andrew Coppin 23 Aug '10

23 Aug '10

gdweber(a)iue.edu wrote: > I hope it does work on Windows! I don't know of any reason why not, > but I haven't tested it on Windows. Please let me know if there's > any problem on that platform. > Unfortunately, yes: Indirectly it requires the "curl" package. Since that's a binding to a C library, it won't build on Windows. (I have every reason to believe that everything else will work though...)

10 20

Compiling UHC
by Henk-Jan van Tuyl 23 Aug '10

23 Aug '10

L.S., I am trying to compile the current release of UHC (1.0.1); I started with the installation of the most recent version of uulib and uuagc. When running make uhc I received the following message: EH\Util\CompileRun.hs:46:7: Could not find module `UU.DData.Scc': Use -v to see a list of the files searched for. This module is not in the most recent version of uulib, so I installed uulib-0.9.10, but then I received the message: EH\Util\CompileRun.hs:46:7: Could not find module `UU.DData.Scc': It is a member of the hidden package `uulib-0.9.10'. Use -v to see a list of the files searched for. What can I do to get UHC compiled? (I am using Haskell Platform 2010.2.0.0) Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html --

2 1

Simple Sudoku solver using Control.Monad.Logic
by azwhaley 23 Aug '10

23 Aug '10

Hello All, Apologies if some have you have got this twice but I posted this once via fa.haskell on Goggle but I don't think it goes anywhere outside Google. In an attempt to learn how to use monads, I've tried to write a simple sudoku solver using the LogicT monad. I think it works but it is extremely slow, in fact it won't finish at all if I attempt to enforce the grid constraints. Just using row and column constraints, it will finish for some problems. Am I doing something dreadfully wrong here or is this just a hard problem to solve ? Thanks Andrew here's the listing :- module Main where import Control.Monad.Logic import Data.List (delete, (\\)) board :: [[Int]] board = [ [7, 9, 0, 0, 0, 0, 3, 0, 0], [0, 2, 0, 0, 0, 6, 9, 0, 0], [8, 0, 0, 0, 3, 0, 0, 7, 6], [0, 0, 0, 0, 0, 5, 0, 0, 2], [0, 0, 5, 4, 1, 8, 7, 0, 0], [4, 0, 0, 7, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0]] -- accessors for row, column and grid row b = (b!!) col b c = [x!!c | x <- b] grid b g = (t 0) ++ (t 1) ++ (t 2) where t i = take 3 $ drop x $ b !! (y + i) x = 3 * (g `mod` 3) y = 3 * (g `div` 3) -- Ensures all numbers in the list are unique unique :: [Int] -> Bool unique r = null (foldl (\a x -> delete x a) [x | x <- r, x /= 0] [1..9]) choose choices = msum [return x | x <- choices] -- Test a cell (0 = unknown value) test :: Int -> Logic [Int] -> Logic Int test 0 c = do choices <- c choose choices test x c = return x -- helper to produce a diff list from a wrapped monadic list mdiff :: [Logic Int] -> [Int] -> Logic [Int] mdiff a c = do i <- sequence a return ([1..9]\\(i++c)) -- the actual solver - attempts to limit choices early on by using diff list of remaining values sudoku :: Logic [[Int]] sudoku = do solution <- foldl (\b r -> do m <- b row <- sequence $ foldr (\(n,x) a -> (test x (mdiff a $ col m n)):a) [] [(n,x) |x <- r | n <- [0..8]] guard $ unique row sequence [guard $ unique $ col m i | i <- [0..8]] return (m ++ [row]) ) (return []) board sequence $ [guard $ unique $ grid solution i | i <- [0..8]] return solution -- solve and print main = do let solution = observe sudoku sequence [print s | s <- solution]

6 9

Trouble with winGHCi
by David Webster 23 Aug '10

23 Aug '10

I just installed Haskell 2010.2.0.0 on Windows XP Pro SP3. When I run winGHCI, I briefly get a displayed window, immediately followed by a "black screen". I have to restart my computer to get rid of it. I have been advised that this is a bug and wonder if it can be fixed. David Webster

2 1