[Haskell-cafe] Re: Parsec, updateState, and failure
Dimitry Golubovsky [EMAIL PROTECTED] wrote: If a parser which updated user state fails, will such update be reverted? I have no idea, I gave up before investigating that far. You want to avoid state at any cost, even more so if the state would influence parsing: spaghetti and headaches lay ahead. In the end I did three passes: two times parsec and one time something similar to accumMap. Now that I'm thinking of it, it would be nice if parsec supported spans in source positions, so that you can report errors like XYZ at foo.bar line 3 column 2 in ZYX spanning line 2-4 column 34-20. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Parsec, updateState, and failure
On Sat, May 31, 2008 at 12:12 PM, Achim Schneider [EMAIL PROTECTED] wrote: Dimitry Golubovsky [EMAIL PROTECTED] wrote: If a parser which updated user state fails, will such update be reverted? I have no idea, I gave up before investigating that far. You want to avoid state at any cost, even more so if the state would influence parsing: spaghetti and headaches lay ahead. In the end I did three passes: two times parsec and one time something similar to accumMap. If you really really wanted state that doesn't un-roll when parsing fails, this should work (but is untested): type MyParser = ParsecT String () (State MyState) runMyParser :: MyParser a - String - SourceName - MyState - (Either ParseError a, MyState) runMyParser m in name state = flip runState state $ runPT m in name You can then use 'get' and 'set'. But as you suggest, that way may be madness. -Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
