[Haskell-cafe] Re: Re: A parsec question

2010-10-03 Thread Ben Franksen 
Antoine Latter wrote:
 On Sun, Oct 3, 2010 at 11:55 AM, Ben Franksen ben.frank...@online.de
 wrote:
 Stephen Tetley wrote:
 Does this one give the expected error message for Parsec3.1 -
 unfortunately I can't test as I'm still using Parsec 2.1.0.1.

 parser = block (many digit ? digit)

 Unfortunately, no.

 Hey folks, sorry about this one - my changes to parsec in 3.1 made
 these error messages worse. I've sent a patch off to the maintainer
 which fixes the examples in this thread.

Thanks! I hope we get a new minor release with these fixes soon. I love
parsec-3 very much, especially since you fixed the speed problems.

Cheers
Ben

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Re: A parsec question

2010-09-29 Thread Ben Franksen 
Daniel Fischer wrote:
 On Wednesday 29 September 2010 19:10:22, Ben Franksen wrote:
 
  Note the last line mentions only '}'. I would rather like to see
 
expecting } or digit
 
  since the parser could very well accept another digit here.
 
 parsec2 did that, I don't know whether that change is intentional or
 accidental.

This looks more like a bug than a feature to me. I checked parsec-3.0.1 and
it behaves like parsec-2, i.e. behaves as I expected.

  (1) What is the reason for this behaviour?
  (2) Is there another combinator that behaves as I would like?
  (3) Otherwise, how do I write one myself?

 I just saw that Christian Maeder answered a similar question recently. I

 tried his suggestion of using manyTill and bingo:
  {-# LANGUAGE NoMonomorphismRestriction #-}
  import Control.Applicative ((*),(*))
  import Text.Parsec
  block p = char '{' * p * char '}'
  parser = block (manyTill digit (char '}'))
  main = parseTest parser {123a}
 You would need
 
 block (manyTill digit (lookAhead (char '}'))
 
 to replicate the behaviour of block (many digit).

Right, so it gets even more complicated.

 Is there a non-greedy variant of 'many' so
 that modularity gets restored and efficiency is not lost?

So many questions...

Cheers
Ben

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe