- Haskell-Cafe - Haskell.org

Mutable variables eliminated from .NET | Lambda the Ultimate
by dons＠cse.unsw.edu.au 02 Apr '07

02 Apr '07

As seen on reputable language news site, Lambda the Ultimate. http://lambda-the-ultimate.org/node/2164 Mutable variables eliminated from .NET Redmond, WA: At an unusual press conference held this Sunday morning, Bill Taylor, Microsoft's General Manager of Platform Strategy, announced that after much research into the causes of security holes and instabilities, Microsoft will eliminate mutable variables from the .NET platform and its languages, including C# and VB.NET. "One of our top researchers found that mutable variables were the major root cause preventing us from achieving the great user experience we always strive to deliver," said Taylor. "Once we realized that, eliminating them from .NET was a no-brainer." Given that this announcement was made on a Sunday, reactions have been limited so far, but one prominent VB.NET developer commented that "Compared to the switch from VB6 to VB.NET, this ought to be a breeze." A C# developer was heard to say, "After anonymous delegates, monads shouldn't be a problem." To ensure wide penetration of this significant update, Microsoft will be issuing updated Windows CDs to all licensed customers, free of charge. The new CDs can be identified by the distinctive holographic "Haskell Inside" logo, featuring a holographic version of this[1] portrait of Simon Peyton-Jones, grinning from ear to ear. [1] http://research.microsoft.com/~simonpj/GIFs/spj-snow.jpg

2 1

Re: [Haskell-cafe] ghc-6.7.20070330 on Mac OS X
by Ruben Zilibowitz 02 Apr '07

02 Apr '07

Hi, I managed to build it eventually using the instructions on: http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX Sorry to Greg - I accidentally sent this to your personal email address first. Ruben On 02/04/2007, at 4:34 AM, Gregory Wright wrote: > > Hi Ruben, > > The GHC wiki also has information on this, and should be your first > stop if you are experiencing build problems: > > http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX > > At least under MacPorts, I have had no trouble building 6.7-20070330. > I will be releasing a new portfile for ghc-devel in a few days that > will > build the latest from the darcs repository. > > Best Wishes, > Greg > > On Apr 1, 2007, at 11:50 AM, Pepe Iborra wrote: > >> (redirecting to glasgow-haskell-users) >> >> It is well known that the readline lib that comes with OS X is no >> good, and you need to use a replacement. A nice post from the >> blogosphere explaining all this: >> >> http://mult.ifario.us/articles/2006/10/17/ghc-6-6-and-mac-os-x- >> readline-quick-fix >> >> If that doesn't help, please post the errors that you get when >> building the readline package. >> >> Cheers >> pepe >> >

1 0

Re: [Haskell-cafe] Data.ByteStream.Char8.words performance
by Duncan Coutts 01 Apr '07

01 Apr '07

On Sun, 2007-04-01 at 17:25 +0200, Thomas Schilling wrote: > On 31 mar 2007, at 04.09, Duncan Coutts wrote: > > > > The ByteString libs was more-or-less the first high performance thing > > that we wrote and we've learnt plenty more since then. I think > > there's a > > good deal more performance too eek out of it yet, both at the low and > > high level. > > Is there some document available explaining those findings (other > than the ByteString paper)? Not yet. Duncan

1 0

String to Word64 Conversion
by Ian Sefferman 01 Apr '07

01 Apr '07

I've been spending a lot of time trying to find a clean way to convert from a String to a Word64 for the Crypto library. Specifically, we're trying to encrypt the strings with Blowfish. The type for the encrypt function is: encrypt :: (Integral a) => a -> Word64 -> Word64 I assume I would want something like: toWord64s :: String -> [Word64] toWord64s = .... myEncrypt string = map (Blowfish.encrypt myKey) (toWord64s string) I would have to imagine that encrypting strings is a fairly common thing to do, so a conversion should be trivial, but I can't seem to find anything on it. I feel like I must be missing something rather obvious here. Am I? Thanks, Ian

1 0

ghc-6.7.20070330 on Mac OS X
by Ruben Zilibowitz 01 Apr '07

01 Apr '07

I am trying to build this version of GHC on Mac OS X. I'm currently using GHC 6.6. The build is failing with the following error: ghci/InteractiveUI.hs:69:7: Could not find module `System.Console.Readline': Use -v to see a list of the files searched for. <<ghc: 310591992 bytes, 51 GCs, 4238510/9457140 avg/max bytes residency (4 samples), 26M in use, 0.02 INIT (0.00 elapsed), 2.11 MUT (15.73 elapsed), 0.31 GC (0.36 elapsed) :ghc>> make[2]: *** [depend] Error 1 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 So it seems I need to install the Readline library. But building the Readline library is also giving me errors on my system. Just wondering if someone else has managed to build ghc-6.7.x on Mac OS X? If so, what did you need to do? Cheers, Ruben

1 0

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

HGL on Mac OS X
by Ruben Zilibowitz 01 Apr '07

01 Apr '07

Hi, Has anyone got the GHC module HGL to work on Mac OS X? If so I'd be very interested to know how. Cheers, Ruben

2 1

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 31 Mar '07

31 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 31 Mar '07

31 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