* Antoine Latter [2010-06-13 16:47:28-0500]

On Sun, Jun 13, 2010 at 4:17 PM, Roman Cheplyaka wrote:

...

Suppose I have some parser 'p'. I want to parse it as well as get its span in the text. So I could write

\begin{code] pWithLocation = do  loc_start <- getPosition  pval <- p  loc_end <- getPosition  return (pval,loc_start,loc_end) \end{code}

except that loc_end gives me the location _after_ 'p'. In case when 'p' has consumed trailing newline I see no way to recover the end location of 'p' (it is the last column of the previous line).

So, can I do anything with this without patching parsec?

I use parsec3 if it matters.

Can you use a parser which doesn't consume leading/trailing whitespace?

Or somehow layer the parsers so that the whitepsace munching happens outside of parseWithLocation.

Of course most parsers don't consume trailing newlines. But I was writing general function to use in many places in the code which would recover the end location. In most cases it just subtracts 1 from the column number, but what if it just happened so that column number is 1? So I got an impression that this way of obtaining the end location is at least ugly. It would be better if there was a function parseWithLocation :: Parser a -> Parser (a, SourcePos, SourcePos) which, I guess, is easy to implement within Parsec without any such hacks. -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain

On 6/14/10 0:10, Roman Cheplyaka wrote:

Of course most parsers don't consume trailing newlines. But I was writing general function to use in many places in the code which would recover the end location. In most cases it just subtracts 1 from the column number, but what if it just happened so that column number is 1?

Parsers can be composed of lots of functions, but eventually all the actual consumption of symbols boils down to calls to Text.Parsec.Prim.tokenPrimEx. This is where you need to address your problem: find the places in your code where this function is called (or the derived tokenPrim or token) and intercept there. Hopefully you have defined your own 'satisfy' function and need only change that one. Once you've found those places, there's multiple ways to solve the problem. For example, you could keep track of the last interesting (=non-whitespace) position. Or you could parse the whitespace in a separate phase. There is no way to retroactively intercept these calls, which I think is a flaw in the design of Parsec. It would have been nice to have a 'runParsecWith myTokenPrimEx', or better yet capture the Parsec primitives in a type class. Groetjes, Martijn.