August 2009 - Haskell-Cafe

Re: quick and dirty file parsing (was: no subject)
by John Lato 22 Aug '09

22 Aug '09

> From: staafmeister <g.c.stavenga(a)uu.nl> > > Thank you for the reply. > > > Thomas ten Cate wrote: >> >> Although you most certainly can use a State monad, in most problems >> this isn't necessary. Most algorithms that you need to solve >> programming contest problems can be written in a purely functional >> style, so you can limit monadic code to just a few helper functions. >> > > Yes I know but there are a lot of problems requiring O(1) array updates > so then you are stuck with IO again Depending on the problem, you may be able to find a better data type than an array. Of course, since we're discussing generalities it's hard to make any specific recommendations. > > Thomas ten Cate wrote: >> >> For example, this reads input in the style you mention (assuming the >> strings don't contain whitespace): >> >>> import Control.Monad >>> >>> answer = id >>> >>> parse [] = [] >>> parse (s:p:r) = (s, (read p) :: Int) : parse r >>> >>> run = getLine >> getLine >>= putStrLn . show . answer . parse . words >>> >>> main = flip replicateM_ run =<< readLn >> >> The answer function would be a pure function that computes the answer >> for a particular run. This main function is reusable for all problems >> with many runs. >> >> Observe that the number of edges (e), provided as a convenience for >> memory allocation in many other languages, is not even necessary in >> Haskell :) >> > > Yes you're main is short. But how would you do it elegantly if > instead of line breaks and spaces one would have only spaces. > Every thing on one big line. My C code would not mind one bit. If I read it properly, this code won't either. The "words" function at the end of the pipeline will split tokens on any whitespace. > > > Thomas ten Cate wrote: >> >> (If anyone knows a better way than explicit recursion to map over a >> list, two elements at a time, or zip its even elements with its odd >> elements, I'd love to hear! I can imagine a convoluted fold with a >> boolean in its state, but it's ugly.) >> > > Yes I missed such a function in a couple of problems I wanted to solve. > I would expect a generic function > groupN::Int -> [a] -> [[a]] > that groups a list into groups of N I often use this function as well. I think it's not in the libraries because it's so simple to define: groupN :: Int -> [a] -> [[a]] groupN n [] = [] groupN n xs = let (h,t) = splitAt n xs in h:groupN n t Or, for a nonrecursive version: groupN2 = fix g where g f n [] = [] g f n xs = let (h,t) = splitAt n xs in h: f n t but that's probably not what you had in mind. I've found that using unfoldr is simpler than fold if you wish to use HOFs to accomplish this, but neither is as simple as explicit recursion. John Lato

1 0

Requesting suggestions for the GraphViz library
by Ivan Lazar Miljenovic 22 Aug '09

22 Aug '09

Whilst I've apparently been on holidays overseas, I was bored enough (and frustrated enough with it) to re-write large parts of the GraphViz library. In particular, I now use a pretty-printing class and a new parsing class so I think the problem with quotes is over \o/ However, there are some design decisions I'd like advice on from users of this library; these are items that I can implement either way but I'm not sure what other people would prefer: * I have re-written large parts of the overall DotGraph and associated data structures, with one difference being that they are polymorphic in the node type; this should make the eventual change to the generic graph class (whenever we get around to doing it) simpler. However, I have left the ID of the DotGraph and the new DotSubGraph data structures as being the GraphID type (which is an algebraic type with number, string and URL support to match the official types of values understood by GraphViz); should I leave it as this or make them polymorphic in the Graph ID type as well? That is, you would have something like "DotGraph l n", with `l' being the type of the GraphIDs and `n' being the type of the node IDs. * With parsing of Dot code, the new data structure layout now more fully/correctly supports upstream by specifying a "DotStatements" data structure for use with DotGraph and DotSubGraph; DotStatements contains a list of (Global) Attributes, a list of DotSubGraphs, a list of Nodes and a list of Edges. At the moment, the parser expects these four types of statements to indeed be listed in that order, though it would be feasible to have the parser accept them in any order and then split them into these four types. Note that this could change the behaviour of how the graph is drawn (specifically in terms of where the Attributes are listed). Do people want a fully-fledged/capable parser or is the current setup sufficient? * The FGL <-> DotGraph functions now have the option to take a Bool parameter which indicates whether the specified graph is directed or undirected (with primed versions attempting to automatically determine this). If the graph is indicated to be undirected, then an edge (n1,n2) is kept if n1 <= n2; should I replace this Bool with a ternary algebraic type that allows the user to indicate that the graph is undirected but to keep all edges? * In the current available release, I had rudimentary error detection support for misuse of attributes. I have re-written this to an extent, and can do so even more to find even more possible errors (e.g. duplicate node IDs); do people actually care about this type of error detection? Am I just wasting my time on this? * With Color values (and since the issue seems to have re-arisen about spelling regarding Russell O'Connor's colour package, I use the American spelling because that's what upstream uses), I do not as yet bother matching up String color names with the colorset being used, etc. Something like this would require a State-based parser; does anyone care enough about this that they want it? The same thing goes for LayerSep, etc. Note that the user would then have to check themselves to make sure that they are using these correctly (that is, they have previously set which colorset they are using). If you're interested in seeing exactly what I've done, the darcs repo is at http://code.haskell.org/graphviz. Han Joosten has already asked me to implement record-based shapes, which I'll be looking at at some point to see how I can implement it into the current system. Otherwise, out of the 7 items on the TODO list I had from the previous version, this as-yet unreleased version has fixed 4 of them. If there's any other requests on what to do, please let me know. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 0

Re: [Haskell-cafe] Re: Where do I put the seq?
by Peter Verswyvelen 21 Aug '09

21 Aug '09

Not at all, use it for whatever you want to :-) I'm writing this code because I'm preparing to write a bunch of tutorials on FRP, and I first wanted to start with simple console based FRP, e.g. making a little text adventure game, where the input/choices of the user might be parsed ala parsec, using monadic style, applicative style, and arrows, and then doing the same with FRP frameworks like Yampa, Elera, Reactive, etc... After that I would start writing tutorials that use OpenGL, making some very simple games, again with the above approaches, and ending with a conversion of a very old game of mine (Zarathrusta written in assembler from 1991, which was based on Thrust <http://www.bytecellar.com/archives/000106.php>from 1986, converted by myself in C++ to PocketPC as G-Pod<http://www.handango.com/catalog/ProductDetails.jsp?productId=16574&platform…>, and so I would like to make a version in Haskell that runs on the iPhone :-) This of course is a lot of work, and I would like to put this on the Haskell wiki or a blog or something, so others can contribute and comment. I would like to show real examples that explain the shortcomings of the FRP approaches, because now this is still a bit blurry to me. On Wed, Aug 19, 2009 at 5:43 PM, David Leimbach <leimy2k(a)gmail.com> wrote: > This Monad you've created is quite excellent. I was trying to do something > like this about a year ago, to make the input and output handling of an > interactive bowling score card work nicely. I kept running into issues, and > did not believe that seq was going to do the trick. Nice work! > This is a very useful monad I think, it could be called "Prompter" or > something to that effect. > > Do you mind if I use it in some of my code? > > Dave > > > On Wed, Aug 19, 2009 at 8:42 AM, Peter Verswyvelen <bugfact(a)gmail.com>wrote: > >> LOL. Maybe we should have that coffee together ;-) at least virtually! >> >> On Wed, Aug 19, 2009 at 5:39 PM, David Leimbach <leimy2k(a)gmail.com>wrote: >> >>> Argh... I too have been up too late :-). I edited THE WRONG FILE! No >>> wonder your change didn't take effect! :-/ >>> Time for coffee I suppose. >>> >>> >>> On Wed, Aug 19, 2009 at 8:38 AM, David Leimbach <leimy2k(a)gmail.com>wrote: >>> >>>> This doesn't seem to be working for me interactively though on a Mac. I >>>> still get "Welcome" before I've entered text. >>>> >>>> >>>> On Wed, Aug 19, 2009 at 8:25 AM, Peter Verswyvelen <bugfact(a)gmail.com>wrote: >>>> >>>>> I fixed it myself but it's really tricky :-) >>>>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330 >>>>> >>>>> <http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330>The idea is, >>>>> that when the input is requested, the output that is then generated must be >>>>> in sync with the input. >>>>> >>>>> inp = S $ \s i -> let r = (*s** **`**D**.**append**`** **(**i** **`**seq**`** **D**.**empty**)*, head i) in (tail i, r) >>>>> >>>>> >>>>> >>>>> I first had >>>>> >>>>> inp = S $ \s i -> let r = (i `seq` *s*, head i) in (tail i, r) >>>>> >>>>> >>>>> But that was too eager, since i syncs the input not with the output, >>>>> but with the function that will generate the output. >>>>> >>>>> Okay, now I can sleep again :-) >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 19, 2009 at 5:12 PM, Peter Verswyvelen <bugfact(a)gmail.com>wrote: >>>>> >>>>>> Thanks, but that doesn't really matter in my example, my code is just >>>>>> buggy, and I'm not sure why. For example if I change my test function so >>>>>> that it outputs lines only, then it still prints Welcome first before asking >>>>>> for input. >>>>>> See e.g. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8328 >>>>>> >>>>>> On Wed, Aug 19, 2009 at 5:00 PM, David Leimbach <leimy2k(a)gmail.com>wrote: >>>>>> >>>>>>> Try LineBuffering. >>>>>>> I do linewise stuff with interact a lot. You'll find stuff like >>>>>>> >>>>>>> unlines . lines >>>>>>> >>>>>>> may help too. In fact I just wrote a blog post about this. >>>>>>> >>>>>>> http://leimy9.blogspot.com >>>>>>> >>>>>>> I'm trying to write some interactive code to automate working with >>>>>>> serial console controlled power strips, so I need to either use Expect >>>>>>> (yuck) or do my own thing. >>>>>>> >>>>>>> Dave >>>>>>> >>>>>>> On Wed, Aug 19, 2009 at 7:35 AM, Peter Verswyvelen < >>>>>>> bugfact(a)gmail.com> wrote: >>>>>>> >>>>>>>> Apparently this particular example happens to work on Mac and Linux >>>>>>>> because of different buffering (thanks Martijn for the help!) >>>>>>>> To make sure we have no buffering at all, the main function should >>>>>>>> be: >>>>>>>> >>>>>>>> main = do hSetBuffering stdout NoBuffering hSetBuffering stdin NoBuffering test >>>>>>>> >>>>>>>> Now I think it should also be *incorrect* on Unix systems. >>>>>>>> >>>>>>>> I guess the way I'm concatenating the strings is not correct, not >>>>>>>> sure. >>>>>>>> >>>>>>>> I would like to use a graphical tool to show the graph reduction >>>>>>>> step by step, to get a better understanding of the laziness & strictness. >>>>>>>> Does such a tool exist? I know people often say this is not usable because >>>>>>>> the amount of information is too much, but I used to be an assembly language >>>>>>>> programmer so I still would like to give it a try :-) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 19, 2009 at 1:07 PM, Peter Verswyvelen < >>>>>>>> bugfact(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> In an attempt to get a deeper understanding of several monads >>>>>>>>> (State, ST, IO, ...) I skimmed over some of the research papers (but didn't >>>>>>>>> understand all of it, I lack the required education) and decided to write a >>>>>>>>> little program myself without using any prefab monad instances that should >>>>>>>>> mimic the following: >>>>>>>>> main = do >>>>>>>>> putStrLn "Enter your name:" >>>>>>>>> x <- getLine >>>>>>>>> putStr "Welcome " >>>>>>>>> putStrLn x >>>>>>>>> putStrLn "Goodbye!" >>>>>>>>> >>>>>>>>> But instead of using IO, I wanted to make my own pure monad that >>>>>>>>> gets evaluated with interact, and does the same. >>>>>>>>> >>>>>>>>> However, I get the following output: >>>>>>>>> >>>>>>>>> Enter your name: >>>>>>>>> Welcome ...... >>>>>>>>> >>>>>>>>> So the Welcome is printed too soon. >>>>>>>>> >>>>>>>>> This is obvious since my monad is lazy, so I tried to put a seq at >>>>>>>>> some strategic places to get the same behavior as IO. But I completely >>>>>>>>> failed doing so, either the program doesn't print anything and asks input >>>>>>>>> first, or it still prints too much output. >>>>>>>>> >>>>>>>>> Of course I could just use ST, State, transformers, etc, but this >>>>>>>>> is purely an exercise I'm doing. >>>>>>>>> >>>>>>>>> So, I could re-read all papers and look in detail at all the code, >>>>>>>>> but maybe someone could help me out where to put the seq or what to do :-) >>>>>>>>> >>>>>>>>> The code is at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316 >>>>>>>>> >>>>>>>>> Oh btw, the usage of DList here might not be needed; intuitively it >>>>>>>>> felt like the correct thing to do, but when it comes to Haskell, my >>>>>>>>> intuition is usually wrong ;-) >>>>>>>>> >>>>>>>>> Thanks a lot, >>>>>>>>> Peter Verswyvelen >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Haskell-Cafe mailing list >>>>>>>> Haskell-Cafe(a)haskell.org >>>>>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >

13 45

Re: How to convert a list to a vector encoding its length in its type?
by John Lato 21 Aug '09

21 Aug '09

> From: David Menendez <dave(a)zednenem.com> > > or, equivalently, by using a higher-order function. > > toPeano :: Int -> (forall n. Nat n => n -> t) -> t > Incidentally, this is the approach used in the type-level library [1], which provides the function: reifyIntegral :: Integral i => i -> (forall n. Nat n => n -> r) -> r The docs describe this as "In CPS style (best possible solution)," although I didn't see any reference for that assertion. Bas, if you'd like some examples, the ForSyDe project [2] has a tutorial on using type-level vectors, which I found helpful when faced with the same problem recently [3], [4]. Cheers, John Lato [1] http://hackage.haskell.org/package/type-level [2] http://www.ict.kth.se/forsyde/files/tutorial/apa.html [3] http://inmachina.net/~jwlato/haskell/iter-audio/src/Sound/Iteratee/Channeli… [4] http://inmachina.net/~jwlato/haskell/iter-audio/examples/channelized_reader…

1 0

Fwd: [BostonHaskell] September meeting polls
by Ravi Nanavati 21 Aug '09

21 Aug '09

I'm forwarding this to haskell-cafe to catch any current or new Boston-area Haskellers who haven't yet joined the BostonHaskell Google group: http://groups.google.com/group/bostonhaskell If you're interested in Boston-area Haskell activity, please join the Google group so you won't miss out on relevant discussions and announcements. Thanks, - Ravi Nanavati ---------- Forwarded message ---------- From: Ravi Nanavati <ravi_n(a)alum.mit.edu> Date: Fri, Aug 21, 2009 at 6:26 PM Subject: [BostonHaskell] September meeting polls To: bostonhaskell(a)googlegroups.com In the interests of getting the September BostonHaskell meeting organized sooner rather than later (and because Doodle polling has been successful so far), I'd like to take a different approach to arranging the meeting. I've created three polls to get the BostonHaskell community's opinion on the three decision points required before I can organize the meeting: 1. When: https://doodle.com/upd74stbe4d95zpb 2. Where: https://doodle.com/fpicbvb927nbb72v 3. What (to talk about): https://doodle.com/7b8kkcb9queiv89k If you're interested in attending the September BostonHaskell meeting, please answer any of the polls you have opinions about. The first two polls are approval polls (where you can indicate which alternatives you approve of), while the third poll (about choosing which talks) is a binary choice. Thank you in advance for participating. I'd also love to hear any comments people have on this new approach to organizing meetings. Thank you, - Ravi Nanavati --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BostonHaskell" group. To post to this group, send email to bostonhaskell(a)googlegroups.com To unsubscribe from this group, send email to bostonhaskell+unsubscribe(a)googlegroups.com For more options, visit this group at http://groups.google.com/group/bostonhaskell?hl=en -~----------~----~----~----~------~----~------~--~---

1 0

testing par with simple program
by Paolino 21 Aug '09

21 Aug '09

Hi, reading a previous thread I got interested. I simplified the example pointed by dons in import Control.Parallel main = a `par` b `pseq` print (a + b ) where a = ack 3 11 b = ack 3 11 ack 0 n = n+1 ack m 0 = ack (m-1) 1 ack m n = ack (m-1) (ack m (n-1)) compiled with ghc --make prova -O2 -threaded timings paolino@paolino-casa:~$ time ./prova +RTS -N1 32762 real 0m7.031s user 0m6.304s sys 0m0.004s paolino@paolino-casa:~$ time ./prova +RTS -N2 32762 real 0m6.997s user 0m6.728s sys 0m0.020s paolino@paolino-casa:~$ without optimizations it gets worse paolino@paolino-casa:~$ time ./prova +RTS -N1 32762 real 1m20.706s user 1m18.197s sys 0m0.104s paolino@paolino-casa:~$ time ./prova +RTS -N2 32762 real 1m38.927s user 1m45.039s sys 0m0.536s paolino@paolino-casa:~$ staring at the resource usage graph I can see it does use 2 cores when told to do it, but with -N1 the used cpu goes 100% and with -N2 they both run just over 50% thanks for comments paolino

2 3

Keeping an indexed collection of values?
by Job Vranish 21 Aug '09

21 Aug '09

I've been in a situation a lot lately where I need to keep a collection of values, and keep track of them by a persistent index. IO and ST refs can do this, but for various reasons I can't/don't want to use them. My first hacked up attempt is as follows: data IndexedCollection a = IndexedCollection { nextKey :: Int, availableKeys :: [Int], items :: (IntMap Int a) } deriving (Show) emptyIndexedCollection :: IndexedCollection a emptyIndexedCollection = IndexedCollection 0 [] empty addItem :: a -> IndexedCollection a -> (Int, IndexedCollection a) addItem a (IndexedCollection nextKey' [] t) = (nextKey', IndexedCollection (nextKey' + 1) [] (insert nextKey' a t)) addItem a (IndexedCollection nextKey' (k:ks) t) = (k, IndexedCollection nextKey' ks (insert k a t)) removeItem :: Int -> IndexedCollection a -> IndexedCollection a removeItem k (IndexedCollection nextKey' ks t) = IndexedCollection nextKey' (k:ks) (delete k t) lookupItem :: Int -> IndexedCollection a -> Maybe a lookupItem k (IndexedCollection _ _ t) = lookup k t Basically: when you add an item, use the first index in availableKeys (if there is one), otherwise use "nextKey" for the index, and then increment it for the next item. When and Item is removed, add it's index to availableKeys This keeps the code for keeping track of/generating indexes hidden away from the rest of the program which is nice, and it remains fairly efficient. Items will be added and removed on very regular basis. Often enough that I'm slightly concerned about overflow of nextKey for very long run times, and hence the availableKeys list. Does anyone know of a better/already existent data structure for handling this problem? Or perhaps a better way of keeping a "key pool" than my availableKeys solution? - Job

4 7

Re: [Haskell-cafe] Right way to implement setPixel function
by CK Kashyap 21 Aug '09

21 Aug '09

thank you very much Job. Regards, Kashyap On Thu Aug 20th, 2009 1:13 PM EDT Job Vranish wrote: >Opps: >setPixel = State setPixel' > >should be: >setPixel x y rgb = State $ setPixel' x y rgb > >- Job > >On Thu, Aug 20, 2009 at 1:05 PM, Job Vranish <jvranish(a)gmail.com> wrote: > >> Your setPixel function is almost ready to work in a State monad >> If you modify your setPixel function slightly like so: >> >> setPixel' :: Int -> Int -> Color -> B.ByteString -> ((), B.ByteString) >> setPixel' x y (r,g,b) image = ((), B.concat [beforePixel, pixel, >> afterPixel]) >> >> and then wrap it in the State monad constructor: >> >> setPixel = State setPixel' >> >> then you can do >> >> drawPixels = do >> setPixel 5 10 (200, 0, 0) >> setPixel 20 1 (0, 200, 0) >> setPixel 90 2 (0, 0, 200) >> >> modifiedImage = execState drawPixels originalImage >> >> See! you were already using a monad and didn't even know it! :D >> >> Performance wise, B.concat is O(n), which is very not good for your >> purpose. It copies the whole string and the optimizer won't be able to >> magically make it go away. For something that works in O(1), you will have >> to use something like STArrays instead of bytestrings. >> >> - Job >> >> >> >> On Thu, Aug 20, 2009 at 2:32 AM, CK Kashyap <ck_kashyap(a)yahoo.com> wrote: >> >>> Hi, >>> I had posted a note on line drawing algo with Haskell some time back. Now, >>> I am trying to write a PNM image. >>> >>> import qualified Data.ByteString as B >>> >>> width = 256 >>> height = 256 >>> bytesInImage = width * height * 3 >>> blankImage = B.pack $ take bytesInImage (repeat 0) >>> >>> type Color = (Int,Int,Int) >>> setPixel :: B.ByteString -> Int -> Int -> Color -> B.ByteString >>> setPixel image x y (r,g,b) = B.concat [beforePixel, pixel, afterPixel] >>> where >>> beforePixel = B.take before image >>> afterPixel = B.drop (before+3) image >>> pixel=B.pack [(fromIntegral r),(fromIntegral >>> g),(fromIntegral b)] >>> -- number of bytes before the 3 bytes of >>> -- the pixel at x y >>> before = (y * width * 3) + (x * 3) - 3 >>> >>> main = do >>> putStrLn "P6" >>> putStrLn ( (show width) ++ " " ++ (show height) ) >>> putStrLn "255" >>> -- Set a red pixel at 100 100 >>> B.putStr (setPixel blankImage 100 100 (255,0,0)) >>> >>> >>> Can I please have some review comments on the code above? Would recreating >>> the entire ByteString for each setPixel be an overhead? >>> Also, I am barely beginning to grasp the Monad concept....I was wondering >>> if there could be a monadic style of implementation of this - that could >>> potentially have a series of setPixels inside a do block? >>> >>> Regards, >>> Kashyap >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >>

1 0

Parsec lookahead and <|>
by Martijn van Steenbergen 21 Aug '09

21 Aug '09

Goedemiddag café, Consider the following function, using parsec-3.0.0: > la :: Parsec String () (Maybe Char) > la = lookAhead (optionMaybe anyChar) *Lookahead> parseTest (char 'a' <|> char 'b') "a" 'a' *Lookahead> parseTest (char 'a' <|> char 'b') "b" 'b' *Lookahead> parseTest (la *> char 'a' <|> char 'b') "a" 'a' *Lookahead> parseTest (la *> char 'a' <|> char 'b') "b" parse error at (line 1, column 2): unexpected "b" expecting "a" The first three work fine and as expected, but the fourth example fails where I would expect success. I know <|> won't try the rhs if the lhs consumed input, but lookAhead's documentation promises not to consume any input. Is this a bug in Parsec or am I missing something? Thanks, Martijn.

4 5

Re: Parsec lookahead and <|>
by Daniel Fischer 21 Aug '09

21 Aug '09

Apologies to Christian for the double post, didn't look at the To-field. Am Thursday 20 August 2009 20:21:30 schrieben Sie: > Daniel Fischer wrote: > > Am Donnerstag 20 August 2009 13:44:15 schrieb Martijn van Steenbergen: > >> Goedemiddag café, > >> > >> Consider the following function, using parsec-3.0.0: > >>> la :: Parsec String () (Maybe Char) > >>> la = lookAhead (optionMaybe anyChar) > >> > >> *Lookahead> parseTest (char 'a' <|> char 'b') "a" > >> 'a' > >> *Lookahead> parseTest (char 'a' <|> char 'b') "b" > >> 'b' > >> *Lookahead> parseTest (la *> char 'a' <|> char 'b') "a" > >> 'a' > >> *Lookahead> parseTest (la *> char 'a' <|> char 'b') "b" > >> parse error at (line 1, column 2): > >> unexpected "b" > >> expecting "a" > >> > >> The first three work fine and as expected, but the fourth example fails > >> where I would expect success. I know <|> won't try the rhs if the lhs > >> consumed input, but lookAhead's documentation promises not to consume > >> any input. Is this a bug in Parsec or am I missing something? > > > > Bad bug in Parsec (from the beginning, the same happens in parsec-2), I'd > > say. > > I'd say, its a feature. lookAhead returns whatever its argument returns. > So in this case it returns "Consumed" without consuming. In that case, the comment "lookAhead p parses p without consuming any input." from the parsec-3 docs is highly misleading. But lookAhead returning Consumed is not only counterintuitive, try parseTest (many la) "a" for a nice memory bomb. > > You can always wrap around a "try" to force the alternative: > > parseTest (try (la >> char 'a') <|> char 'b') "b" > > Cheers Christian > > Maybe it should have been: > > la >> (char 'a' <|> char 'b') > > in the first place.

2 1