March 2007 - Haskell-Cafe

Re: Why the Prelude must die
by David House 28 Mar '07

28 Mar '07

On 28/03/07, Jeffrey Yasskin <jyasskin(a)gmail.com> wrote: > I would vote for a Combinators module with the most important > combinators, and a somewhat larger Prelude to support quick scripts > and demonstrations. I'd hate to have to import a module just to get at ($). Like I've mentioned before, some combinators are so ubiqutos they're almost like syntax. Seeing as the actual syntax will always be in scope, these common combinators would also have to be in scope all the time, which means placing them in the narrowed Prelude. -- -David House, dmhouse(a)gmail.com

1 0

Haskell and a new web developement mailinglist?
by Marc Weber 28 Mar '07

28 Mar '07

I've been talking to Chris Eidhof the last days and we'd like to suggest adding another specialized haskell mailinglist: Haskell and web developement. I think the global interest will increase in the feature, libraries are evolving and it would be nice to have a place to discuss them. Any comments? If there is no veto where can I request it? haskell-admin(a)haskell.org ? Marc

5 7

cost of modules
by Fawzi Mohamed 28 Mar '07

28 Mar '07

I decided to cleanup my program by splitting it in different modules. As I was curious about the cost of splitting it, or dually the efficiency of the intermodule optimization I timed it before and after the split. These are the results (ghc-6.6.20070129 on Linux AMD64): Original: 3 Modules with the computational one with an export list real 0m0.385s user 0m0.378s sys 0m0.003s time:100% Variant 1: split computational module in 6 submodules without export list, kept computational module reexporting the stuff with an export list real 0m0.467s user 0m0.464s sys 0m0.003s time: 122% Variant 2: like Variant 1 but removing the old computational module (no reexport list) 134% real 0m0.513s user 0m0.506s sys 0m0.003s All the functions in my modules have type specialized signatures, so non-specialization should almost never be an issue. The module with the Main function was not the exported one. So 20% speed hit, I had hoped for 0, but it is not unbearable (even if my code has to be as fast as possible, this was a very short run), probably I will keep it split to have cleaner code. Not I will have to write an export list for each module a see it the things improve, and how much. If someone has an idea on how else I can improve timings please tell me. Fawzi

7 9

infinite lists
by Matthias Fischmann 27 Mar '07

27 Mar '07

hi, it just took me an eternity to undestand a bug in my code *after* i had narrowed it down to eight lines or so. and as these bugs go, i feel very good about having found it and have to share it. although it's probably not that exciting to anybody except me. (-: here is the bug, narrowed to four lines. a function that only sometimes terminates. f = do n <- randomRIO (0,5) let l = replicate n '*' i = join $ repeat l -- infinite extension print (take 12 i) how many seconds does it take you to shout "you idiot!"? :-) spoiler below. (what would have been your fix?) cheers, matthias =================================================================== spoiler. the problem is that l is sometimes empty, and taking an element out of an infinite concatenation of empty lists takes even longer than understanding that that takes quite long. just deal with the empty-list case separately: g = do n <- randomRIO (0,5) let l = replicate n '*' i | null l = [] | otherwise = join $ repeat l print (take 12 i)

3 3

(newbie) instance Enum MyType where, smarter way?
by Adrian Neumann 27 Mar '07

27 Mar '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello, I defined an enumeration datatype like this data MyType = One | Two | Four | Eight and want to make it an instance of the class Enum. deriving Enum won't do what I want, as it labels the items 0,1,2,3. Is there a better way to do this than instance Enum MyType where fromEnum One = 1 fromEnum Two = 2 ... toEnum 8 = Eight Something like instance Enum MyType where fromEnum One = 1 fromEnum x = 2*pred x toEnum 1 = One toEnum x = succ (toEnum x `div` 2) Which doesn't work because succ and pred are not (properly?) defined. Is there a way to let deriving Enum do *some* of work (i.e. defining succ and pred) while manually defining the other functions? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCTRJ11V8mqIQMRsRA4GFAJwKaxQoKdEW91pHUskzJadDvh7lXgCeLg6P dmQKcjRZEg4fqoZfQ4jOuhg= =RWQ+ -----END PGP SIGNATURE-----

3 2

Re: [Haskell] Lift Info [moving to -cafe]
by Andrew Wagner 27 Mar '07

27 Mar '07

I'm no expert, but I will point you to 2 links that I think will be helpful on this topic on the wiki: http://www.haskell.org/haskellwiki/Lifting (especially if you're familiar with functors) http://www.haskell.org/haskellwiki/Simple_StateT_use (for a simple example with a monad transformer) I'm also re-directing this question to haskell-cafe, where it's more likely to get a better response. Best of luck! On 3/27/07, Dave(a)haskell.org <Dave(a)haskell.org> wrote: > I've been looking for an explanation of the Haskell lift function which > I don't yet get. There seem to be two kinds of lifting, one of which is > making normal functions usable inside monads. I don't understand either > type. I've googled for lift but what I've found has not helped me much. > Is there a tutorial on what problem using lift solves? > > Thanks, > > Dave Feustel > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0

Lazy parser with parsec.
by David Brown 27 Mar '07

27 Mar '07

I'm trying to figure out how to write a simple parser in Parsec to tokenize a subset of RTF. The problem is that I haven't been able to come up with a way of writing the parser that doesn't try consuming all of the input just to return the first token. The 'many' primitive's implementation uses an accumulator, and obviously has to parse to the end. Trying to iterate myself causes stack overflows on large inputs. Does anyone know of any existing Parser parsers that don't consume their entire input, or am I probably best off making my own parser. Thanks, David

3 3

Re: Can we do better than duplicate APIs? [was: Data.CompactString 0.3]
by Benjamin Franksen 26 Mar '07

26 Mar '07

Jean-Philippe Bernardy wrote: > Please look at http://darcs.haskell.org/packages/collections/doc/html/Data-Collections.html > for an effort to make most common operation on bulk types fit in a > single framework. The last time I looked at this (shortly after you started the project) I wasn't sure if I would want to use it. Now it seems like an oasis in a desert to me. I am pretty much impressed, for instance, you managed to unify all the nine existing 'filter' types into a common type class. Cool. The only hair in the (otherwise very tasty) soup is "Portability: MPTC, FD, undecidable instances" which doesn't sound like it is going to replace the Prelude any time soon ;-) Never mind: I definitely consider using this instead of importing all these different Data.XYZ modules directly (and, heaven forbid, having to import them qualified whenever I need two of them in the same module). Do you forsee any particular obstacle to an integration (=providing the appropriate instances) of e.g. CompactStrings? I would even try to do this myself, as an exercise of sorts. How difficult is it in practice to work with 'undecidable instances'? Are there special traps one has to be careful to walk around? > Also, we expect indexed types to solve, or at least alleviate, some > problems you mention in your "rant". > http://haskell.org/haskellwiki/GHC/Indexed_types I have been hoping for that to resolve (some of) our troubles, but have been confused by the all the back and forth among the experts about whether they offer more, or less, or the same, as MPTCs+fundeps+whatever (and that they will probably not go into Haskell'). BTW, any reason I didn't find your collections library in the HackageDB (other than stupidity on my part)? (Just interested, I already found the darcs repo.) Cheers Ben PS: Since I read and post to the Haskell lists via gmane and a news client: Do mail clients usually respect the follow-up header, such as I insert when cross-posting, so as to restrict follow-ups to the intended list?

1 0

What ever happened to Haskell 98 as a "stablebranch"?
by daniel.is.fischer＠web.de 26 Mar '07

26 Mar '07

Accidentally sent to haskell(a)haskell.org instead of the cafe: > >Diversity is generated by mutations. > > This is hardly a revelation. It was, looong ago. > > My point was that you need two competing components in relative balance to > grow something meaningful. And I'd think the Haskell community could take the part of 'Selektionsdruck' (don't know the correct english term). But you have a good point below, might be too slow for our short lives :( > Cancer growth is based solely on mutation! > > Also I was not theological. Didn't think you seriously were, but you introduced the acronym, was too tempting. > It is the advice to multiply Prelude and use > time to verify them rather cosmic in scale. It implies the assumption that > the world will freeze and wait for the verdict. > > Cheers, Daniel

1 0

Re: [Haskell-cafe] What ever happened to Haskell 98 as a "stablebranch"?
by daniel.is.fischer＠web.de 26 Mar '07

26 Mar '07

> -----Ursprüngliche Nachricht----- > Von: "Andrzej Jaworski" <himself(a)poczta.nom.pl> > Gesendet: 26.03.07 18:34:00 > An: <daniel.is.fischer(a)web.de> > Betreff: Re: [Haskell-cafe] What ever happened to Haskell 98 as a "stablebranch"? > Hi, > > I apologize for mistakenly resending my answer to two lists. > Well, I can understand Simon, he has little choice but to press on, but you > have healthy distance and much wider intellectual angle to see that Haskell > is doomed if new features will come up without any incentive to prune the > tree. Agreed. (Though I'm not sure about "doomed", after all: Jeszcze Polska ... ) And having thought more about it, I'm less optimistic that better alternatives will let their predecessors wither fast enough. But perhaps we could keep the older tree until the new one bears fruit? And I also support the move for a smaller Prelude, only I don't know what to move to Data.Whatever (I strongly dislike the idea of abandoning the Prelude altogether, but I could live with[out] it). > > Cheers, > -Andrew > Cheers, Daniel

1 0