- Haskell-Cafe - Haskell.org

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

Re: [Haskell-cafe] What ever happened to Haskell 98 as a "stablebranch"?
by Andrzej Jaworski 26 Mar '07

26 Mar '07

Daniel Fischer has cared to inform me that: >Diversity is generated by mutations. With due respect, but this is hardly a revelation. My point was that you need two competing components in relative balance to grow something meaningful. Cancer growth is based solely on mutation! Also I was not theological. 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.

1 0

Newbie: a parser for a list of objects?
by Dmitri O.Kondratiev 26 Mar '07

26 Mar '07

Please see my questions inside comments {-- --} : Thanks! --- module Parser where import Data.Char type Parse a b = [a] -> [(b, [a])] {-- Newbie: a parser for a list of objects? I am working with the section 17.5 "Case study: parsing expressions" of the book "Haskell The Craft of Functional Programming", where a parser for a list of objects is defined. I called this function pList in order to avoid confusion with 'list' as a term for data structure. Please help me to understand how pList works (please, see the rest of the code at the end of this message): --} pList :: Parse a b -> Parse a [b] pList p = (succeed []) `alt` ((p >*> pList p) `build` (uncurry (:))) {-- First of all, I don't quite understand why there must be a choice ('alt') between the function ('succeed') that always returns an empty list and the other part? This results in adding [] to the front, why? I thought that 'simplified' version of pList should still work fine. Trying to prove this I wrote : --} pL1 :: Parse a b -> Parse a [b] pL1 p = (p >*> pL1 p) `build` (uncurry (:)) {-- Which, as expected, does not work correctly - just gives an empty list [] - but I don't understand why: *Parser> t1 "12345" [] *Parser> Also, I don't understand why the textbook version of pList gives this result: *Parser> test "12345" [("","12345"),("1","2345"),("12","345"),("123","45"),("1234","5"),("12345","")] *Parser> In particular, I don't understand where the first element ("","12345") of the resulting list comes from? I am trying to figure out how pList recursively unfolds. To my mind operators in the expression: (succeed []) `alt`((p >*> pList p) `build` (uncurry (:))) has the following execution order: 1) >*> 2) 'build' 3) 'alt' It seems that operation >*> should be done as many times as many elements the input list has. Right? Signature: (>*>) :: Parse a b -> Parse a c -> Parse a (b, c) implies that second argument of the expression: p >*> pList p should be of type 'Parse a c' but in this application it is of type 'Parse a b -> Parse a [b]' How can that be? How recursion termination conditinon is expressed in pList? --} none :: Parse a b none inp = [] succeed :: b -> Parse a b succeed val inp = [(val, inp)] suc:: b -> [a] -> [(b, [a])] suc val inp = [(val, inp)] spot :: (a -> Bool) -> Parse a a spot p [] = [] spot p (x:xs) | p x = [(x, xs)] | otherwise = [] alt :: Parse a b -> Parse a b -> Parse a b alt p1 p2 inp = p1 inp ++ p2 inp bracket = spot (=='(') dash = spot (== '-') dig = spot isDigit alpha = spot isAlpha infixr 5 >*> (>*>) :: Parse a b -> Parse a c -> Parse a (b, c) (>*>) p1 p2 inp = [((x,y), rem2) |(x, rem1) <- p1 inp, (y, rem2) <- p2 rem1] build :: Parse a b -> (b -> c) -> Parse a c build p f inp = [ (f x, rem) | (x, rem) <- p inp] test = pList dig t1 = pL1 dig

1 0

What ever happened to Haskell 98 as a "stable branch"?
by Stefan O'Rear 26 Mar '07

26 Mar '07

Upon more reflection... >From the Preface to the Haskell 98 Language and Libraries Report: > Haskell 98 was conceived as a relatively minor tidy-up of Haskell > 1.4, making some simplifications, and removing some pitfalls for the > unwary. It is intended to be a "stable" language in sense the > implementors are committed to supporting Haskell 98 exactly as > specified, for the foreseeable future. In other words, we already have a stable branch of Haskell. Why, then, are we so paranoid about introducing breaking changes in the development branch of haskell? Why are we stuck without the class system extension proposal? Why is Num so still so horribly mangled? Why can I not 'map' over a Set? Why must I use lists of characters if I desire standard sorting? Why can I not get a good error message from read? (If you answer "because H98 is obsolete", then file this away as a must-read after H' is released.) Stefan

4 4

A question about functional dependencies and existential quantification
by Jean-Marie Gaillourdet 26 Mar '07

26 Mar '07

Hi, I am trying to do something like the following: > {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} > module TestCase where > > data Any root = forall pos sel . T root pos sel => ANY pos > > class T root pos sel | pos -> root, root -> sel where > f :: pos -> sel -> Bool > > instance T root (Any root) sel where > f (ANY p) s = f p s There is a multi-parameter type class T with some functional dependencies. And I want do define an almost general type for T, Any root. I would like to have that type in T as well. But ghc is not able to type check f. It gives: > TestCase.hs:10:7: > Couldn't match expected type `sel1' (a rigid variable) > against inferred type `sel' (a rigid variable) > `sel1' is bound by the pattern for `ANY' at TestCase.hs:10:7-11 > `sel' is bound by the instance declaration at TestCase.hs:9:0 > When using functional dependencies to combine > T root pos sel, arising from use of `f' at TestCase.hs:10:18-22 > T root pos sel1, > arising from is bound by the pattern for `ANY' > at TestCase.hs:10:7-11 > at TestCase.hs:10:7-11 > In the pattern: ANY p > In the definition of `f': f (ANY p) s = f p s I think sel1 and sel are equal, because the root in the type of "(ANY p)" on the left side is the same as the root of the type of "f p s" on the right side. From that should follow with help of the functional dependency that sel1 and sel are the same types. Do I misunderstand the type system or is that a weakness of GHC? Or am I trying to do something silly? I have a solution that involves requiring sel to be in Typeable and using cast and I never came across a runtime error, so far. Is there a better way to express that? Any enlightenment is appreciated. Regards, Jean-Marie

2 3

Re: [Haskell-cafe] What ever happened to Haskell 98 as a "stablebranch"?
by Daniel Fischer 26 Mar '07

26 Mar '07

> -----Ursprüngliche Nachricht----- > Von: "Andrzej Jaworski" <himself(a)poczta.nom.pl> > Gesendet: 26.03.07 15:00:47 > An: "Simon Peyton-Jones" <simonpj(a)microsoft.com> > CC: Haskell-Cafe(a)haskell.org > Betreff: Re: [Haskell-cafe] What ever happened to Haskell 98 as a "stablebranch"? > >Haskell is rather a Darwinian sort of place. > > With whole respect. You need two components for evolution to work: the > survival of the fitness and Generator Of Diversity (GOD). Diversity is generated by mutations. Go ahead, be mutagenous. And don't worry about theology, Simon's not GOD's prophet, he's (both of them, actually) just a doctor venerabilis. > > Now, Haskell attracts originality and easily accommodates changes but nobody > burns tires in testing anything so that complexity and learning curve grow > while deficiencies remain dormant. > > Recent threads are a kind of healthy evolutionary pressure (survival of the > fitness), but you insist that Haskell should be committed to GOD;-) > > With great respect, > -Andrzej > With TIC, Daniel

1 0