March 2007 - Haskell-Cafe

ANN: HSH 1.2.0
by John Goerzen 03 Apr '07

03 Apr '07

Hi, I'm pleased to announce HSH 1.2.0. Since version 1.0.0 was announced a few days ago, there have been some improvements: * run is now a function with a polymorphic return type. Depending on the value expected, it can return to you a String representing all output, an exit code, a list of lines of output, etc. runS is now removed. * A number of new helper functions in ShellEquivs. Fixes to readlink and readlinkabs there. * New helper functions runIO (to force an IO () context) and runSL (returns a single line of output, \n stripped) * There are now 82 unit tests. Get it at: http://software.complete.org/hsh -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715

10 29

Why the Prelude must die
by Stefan O'Rear 01 Apr '07

01 Apr '07

This is a ranty request for comments, and the more replies the better. 1. Namespace pollution The Prelude uses many simple and obvious names. Most programs don't use the whole Prelude, so names that aren't needed take up namespace with no benefit. 2. Monomorphism The Prelude defines many data types (e.g Lists), and operations on these types. Because the Prelude is imported automatically, programmers are encouraged to write their programs in terms of non-overloaded operators. These programs then fail to generalize. This is a highly non-academic concern. Many widely used libraries, such as Parsec, operate only on lists and not the newer and more efficient sequence types, such as bytestrings. 3. Supports obsolete programming styles The Prelude uses, and by means of type classes encourages, obsolete and naive programming styles. By providing short functions such as nub automatically while forcing imports to use sets, the Prelude insidiously motivates programmers to treat lists as if they were sets, maps, etc. This makes Haskell programs even slower than the inherent highlevelness of laziness requires; real programs use nub and pay dearly. More damagingly, the Prelude encourages programmers to use backtracking parsers. Moore's law can save you from nub, but it will never clarify "Prelude.read: no parse". 4. Stagnation Because every program uses the Prelude, every program depends on the Prelude. Nobody will willingly propose to alter it. (This is of course Bad; I hope Haskell' will take the fleeting opportunity to break to loop) 5. Inflexibility Because of Haskell's early binding, the Prelude always uses the implementation of modules that exists where the Prelude was compiled. You cannot replace modules with better ones. 6. Dependency Because every module imports the Prelude every module that the Prelude depends on, mutually depends with the Prelude. This creates huge dependency groups and general nightmares for library maintainers. 7. Monolithicity Every module the Prelude uses MUST be in base. Even if packages could be mutually recursive, it would be very difficult to upgrade any of the Prelude's codependents. 8. Monolithic itself Because the Prelude handles virtually everything, it is very large and cannot be upgraded or replaced piecemeal. Old and new prelude parts cannot coexist. 9. One-size-fits-all-ism Because the Prelude must satisfy everyone, it cannot be powerful, because doing so would harm error messages. Many desirable features of Haskell, such as overloaded map, have been abandoned because the Prelude needed to provide crutches for newbies. 10. Portability Because the Prelude must be available everywhere, it is forced to use only least-common-denominator features in its interface. Monad and Functor use constructor classes, even though MPTC/FD is usefully far more flexible. The Class_system_extension_proposal, while IMO extremely well designed and capable of alleviating most of our class hierarchy woes, cannot be adopted. 11. Committeeism Because the Prelude has such a wide audience, a strong committee effect exists on any change to it. This is the worst kind of committeeism, and impedes real progress while polluting the Prelude with little-used features such as fail in Monad (as opposed to MonadZero) and until. 12. There is no escape Any technical defect in Map could be fixed by someone writing a better Map; this has happened, and the result has been accepted. Defects in the PackedString library have been fixed, with the creation and adoption of ByteString. Defects in System.Time have been fixed, by the creation and adoption of Data.Time. Ditto for Binary and Arrays and Network and Regex. But this will never happen for the Prelude. A replacement Prelude cannot be adopted because it is so easy to take the implicit import of the default one. Nobody will go out of their way to 'import Prelude() ; import FixedPrelude'. Psychology trumps engineering. 13. There can be no escape The Prelude was designed by extremely smart people and was considered close to perfect at the time. It is almost universally hated now. Even if all the issues I describe could be fixed (which I consider unlikely), the Prelude will almost certainly be hated just as universally five years hence. 14. My future Given all these issues, I consider the only reasonable option is to discard the Prelude entirely. There will be no magic modules. Everything will be an ordinary library. HOFs like (.) are available from Control.Function. List ops come from Data.List. Any general abstractions can be added in abstract Sequence, Monad, etc. modules. Haskell will regain the kind of organic evolution whose lack currently causes Haskell to lose its lead over Python et al by the day. Stefan

18 33

Parsing words with parsec
by paolino 31 Mar '07

31 Mar '07

Hi, I had a bad time trying to parse the words of a text. I suspect I miss some parsec knowledge. In the end it seems working, though I haven't tested much and this example contains the main features I was looking. *Main> parseTest (parseLine eof) "paolo@gmail sara,mimmo! 9ab a9b ab9 cd\n" ["paolo@gmail","sara","mimmo","cd"] --------------------- manyTillT body terminator joiner = liftM2 joiner (manyTill body (lookAhead terminator)) terminator wordChar = letter <|> oneOf "_@" <?> "a valid word character" nonSeparator = wordChar <|> digit wordEnd = do x <- wordChar notFollowedBy nonSeparator return x word = manyTillT wordChar (try wordEnd) (\b t -> b ++ [t]) <?> "a word" wordStart = do (try nonSeparator >> unexpected "non separator") <|> anyChar lookAhead wordChar nextWord = manyTill anyChar (try wordStart) >> (try word <|> nextWord) parseLine end = do f <- option [] $ return `fmap` try word r <- many $ try nextWord manyTill anyChar end return (f ++ r) ----------- Any comment to simplify this code is welcome. Paolino.

6 7

Data.ByteStream.Char8.words performance
by Dino Morelli 30 Mar '07

30 Mar '07

I noticed something about ByteStream performance that I don't understand. I have a test text document: $ ls -sh test-text-file 956K test-text-file Running this program, using the Prelude's IO functions: > module Main where > > main = do > content <- readFile "test-text-file" > let l = length . words $ content > print l I get: $ time ./a.out 174372 real 0m0.805s user 0m0.720s sys 0m0.008s Running a version of the same thing using Data.ByteStream.Char8: > module Main where > > import qualified Data.ByteString.Char8 as B > > main = do > content <- B.readFile "test-text-file" > let l = length . B.words $ content > print l I see a time that is quite a bit slower: $ time ./a.out 174372 real 0m1.864s user 0m1.596s sys 0m0.012s Changing it to incorporate similar code to the implementation of B.words: > module Main where > > import qualified Data.ByteString.Char8 as B > import Data.Char (isSpace) > > main = do > content <- B.readFile "test-text-file" > let l = length $ filter (not . B.null) $ B.splitWith isSpace > content > print l I see a similar time as with B.words: $ time ./a.out 174372 real 0m1.835s user 0m1.628s sys 0m0.012s And then if I change this to use B.split ' ' instead of isSpace: > module Main where > > import qualified Data.ByteString.Char8 as B > > main = do > content <- B.readFile "test-text-file" > let l = length $ filter (not . B.null) $ B.split ' ' content > print l I get a time that's much more reasonable-looking, compared to the original Prelude.words version: $ time ./a.out 174313 real 0m0.389s user 0m0.312s sys 0m0.004s It seems like the B.splitWith isSpace code is really slow for some reason. Anybody have any idea what's going on? The actual implementation is using isSpaceWord8 which is a case statement looking for a pile of different whitespace characters. -- .~. Dino Morelli /V\ email: dino(a)ui3.info /( )\ irc: dino- ^^-^^ preferred distro: Debian GNU/Linux http://www.debian.org

3 3

Lambdabot not running on XP
by Iain Alexander 30 Mar '07

30 Mar '07

I eventually persuaded Plugin.Pl.Transform.hs to compile by disabling the optimisation, and with other bits of hackery got lambdabot to build. When I run it as lambdabot I get Initialising plugins..... (with lots of '.'s, presumably one '.' per plugin) and then the command prompt returns. There is no sign of a lambdabot running. Any idea where I can start to diagnose what's going wrong? (ghc-6.4.1, lambdabot-4.0, WinXP SP2) -- Iain Alexander ia(a)stryx.demon.co.uk

4 4

Monad/Functor Book
by unknown＠example.com 30 Mar '07

30 Mar '07

Given the amount of material posted at haskell.org and elsewhere explaining IO, monads and functors, has anyone considered publishing a comprehensive book explaining those subjects? (I am trying to read all the material online, but books are easier to read and don't require sitting in front of a computer to do so. Plus I can write in books :-). ) Thanks, Dave Feustel

7 8

Why the Prelude must die
by Andrzej Jaworski 30 Mar '07

30 Mar '07

>What I want to push is a 'mathematically sound' numeric prelude. A proper >numerical prelude should have bona fide mathematical obects like groups, >rings, and fields underlying common numerical classes. Why not Clifford algebra: to simplify mathematical physics, mechanics, computer vision, improve neural networks etc.? That would probably be easier with OCaml-style categorical machine architecture. But then why not go for combinatorial stuff like matroids or graphs? More mathematics in a programming language won't harm general applications written in it. On the contrary, almost any human endeavor could be mathematically structured and thus programmed. Present languages are office-oriented for lack of mathematical knowledge and not any hidden virtue. Cheers, -Andrzej

3 4

Simple task for parsec.
by Paolo Veronelli 29 Mar '07

29 Mar '07

Hi, I had a bad time trying to parse the words of a text. I suspect I miss some parsec knowledge. In the end it seems working, though I haven't tested much and this example contains the main features I was looking. *Main> parseTest (parseLine eof) "paolo@gmail sara,mimmo! 9ab a9b ab9 cd\n" ["paolo@gmail","sara","mimmo","cd"] --------------------- manyTillT body terminator joiner = liftM2 joiner (manyTill body (lookAhead terminator)) terminator wordChar = letter <|> oneOf "_@" <?> "a valid word character" nonSeparator = wordChar <|> digit wordEnd = do x <- wordChar notFollowedBy nonSeparator return x word = manyTillT wordChar (try wordEnd) (\b t -> b ++ [t]) <?> "a word" wordStart = do (try nonSeparator >> unexpected "non separator") <|> anyChar lookAhead wordChar nextWord = manyTill anyChar (try wordStart) >> (try word <|> nextWord) parseLine end = do f <- option [] $ return `fmap` try word r <- many $ try nextWord manyTill anyChar end return (f ++ r) ----------- Any comment to simplify this code is welcome. Paolino.

1 0

Parsing words with parsec
by paolino 29 Mar '07

29 Mar '07

Hi, I had a bad time trying to parse the words of a text. I suspect I miss some parsec knowledge. In the end it seems working, though I haven't tested much and this example contains the main features I was looking. *Main> parseTest (parseLine eof) "paolo@gmail sara,mimmo! 9ab a9b ab9 cd\n" ["paolo@gmail","sara","mimmo","cd"] --------------------- manyTillT body terminator joiner = liftM2 joiner (manyTill body (lookAhead terminator)) terminator wordChar = letter <|> oneOf "_@" <?> "a valid word character" nonSeparator = wordChar <|> digit wordEnd = do x <- wordChar notFollowedBy nonSeparator return x word = manyTillT wordChar (try wordEnd) (\b t -> b ++ [t]) <?> "a word" wordStart = do (try nonSeparator >> unexpected "non separator") <|> anyChar lookAhead wordChar nextWord = manyTill anyChar (try wordStart) >> (try word <|> nextWord) parseLine end = do f <- option [] $ return `fmap` try word r <- many $ try nextWord manyTill anyChar end return (f ++ r) ----------- Any comment to simplify this code is welcome. Paolino.

1 0

A simple parsing task for parsec.
by paolino 29 Mar '07

29 Mar '07

Hi, I had a bad time trying to parse the words of a text. I suspect I miss some parsec knowledge. In the end it seems working, though I haven't tested much and this example contains the main features I was looking. *Main> parseTest (parseLine eof) "paolo@gmail sara,mimmo! 9ab a9b ab9 cd\n" ["paolo@gmail","sara","mimmo","cd"] --------------------- manyTillT body terminator joiner = liftM2 joiner (manyTill body (lookAhead terminator)) terminator wordChar = letter <|> oneOf "_@" <?> "a valid word character" nonSeparator = wordChar <|> digit wordEnd = do x <- wordChar notFollowedBy nonSeparator return x word = manyTillT wordChar (try wordEnd) (\b t -> b ++ [t]) <?> "a word" wordStart = do (try nonSeparator >> unexpected "non separator") <|> anyChar lookAhead wordChar nextWord = manyTill anyChar (try wordStart) >> (try word <|> nextWord) parseLine end = do f <- option [] $ return `fmap` try word r <- many $ try nextWord manyTill anyChar end return (f ++ r) ----------- Any comment to simplify this code is welcome. Paolino.

1 0