Martin Thanks. If you were to take the existing ReadP module, add your stuff, Haddockise it with explanatory text, then I'll put the result in place. ReadP would be much more useful if it had some introductory Haddock documentation too, including a reference to Koen Claessen's paper, if you felt up to doing that too. Many thanks for your help. Simon | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Martin | Sjögren | Sent: 22 July 2004 23:42 | To: libraries@haskell.org | Subject: Combinators for ReadP | | So I was wondering why there weren't any helpful combinators defined | in the ReadP module and found myself rewriting them over and over. I | put a bunch of combinators in the attached module (based on | corresponding combinators in Parsec.Combinator) and it would be neat | if they could be incorporated in the standard ReadP module in some | form. | | Cheers, | Martin
On Fri, 23 Jul 2004 09:14:50 +0100, Simon Peyton-Jones <simonpj@microsoft.com> wrote:
Martin
Thanks. If you were to take the existing ReadP module, add your stuff, Haddockise it with explanatory text, then I'll put the result in place.
ReadP would be much more useful if it had some introductory Haddock documentation too, including a reference to Koen Claessen's paper, if you felt up to doing that too.
Many thanks for your help.
Okay. How does this look? I'm a newbie at haddock, so it may be possible to make it prettier... /Martin
Whoops, the definition of chainl1 should of course be chainl1 p op = p >>= rest where rest x = do f <- op y <- p rest (f x y) +++ return x i.e. rest (f x y), rather than return (f x y). Maybe I should write a test suite too, while I'm at it. Is there any specific location in the cvs tree where test suites should be put?
On Fri, Jul 23, 2004 at 09:14:50AM +0100, Simon Peyton-Jones wrote:
ReadP would be much more useful if it had some introductory Haddock documentation too, including a reference to Koen Claessen's paper, if you felt up to doing that too.
And here I was, completly unaware space and time efficient monadic parsers were even possible! :) Any chance a couple of changes could be made to ReadP 1. let the type of tokens be an argument 2. give Fail a String argument and have it preserve the string passed to 'fail'. I don't think either will adversly affect performance, yet will make it possible to use ReadP as a simple standard (as in comes with the libraries) very lightweight parsing monad without compromising its main goal of implementing a faster Read. John -- John Meacham - ⑆repetae.net⑆john⑈
John Meacham wrote:
2. give Fail a String argument and have it preserve the string passed to 'fail'.
I don't think either will adversly affect performance,
I haven't studied the code for readP, but from experience I can tell that one needs to be very careful to not affect performance when adding error messages. For example, if one wants to combine failure messages from different alternatives, you could force too much evaluation. i.e. When adding this, be very careful not to break the laziness of the current implementation. -- Daan.
On Fri, 23 Jul 2004 17:21:34 -0700, John Meacham <john@repetae.net> wrote:
Any chance a couple of changes could be made to ReadP
1. let the type of tokens be an argument 2. give Fail a String argument and have it preserve the string passed to 'fail'.
I don't think either will adversly affect performance, yet will make it possible to use ReadP as a simple standard (as in comes with the libraries) very lightweight parsing monad without compromising its main goal of implementing a faster Read.
While we're discussing changes, is there an overwhelmingly good reason for the use of local quantification beyond making the type signatures simpler? Writing newtype ReadP r a = R ((a -> P r) -> P r) (like in ContT) would make ReadP completely Haskell98 as far as I can tell. /Martin
John Meacham <john@repetae.net> writes:
possible to use ReadP as a simple standard (as in comes with the libraries) very lightweight parsing monad
Errm, "comes with the libraries" does not necessarily make it standard. As the file header says, Text.ParserCombinators.ReadP is non-portable because it uses local universal quantification. Martin Sjögren <msjogren@gmail.com> writes:
While we're discussing changes, is there an overwhelmingly good reason for the use of local quantification beyond making the type signatures simpler? Writing newtype ReadP r a = R ((a -> P r) -> P r) (like in ContT) would make ReadP completely Haskell98 as far as I can tell.
I think you'll find that without the local universal quantifier, you cannot make ReadP a (useful) instance of Monad, because your 'r' parameter would be fixed across >>=, whereas it really needs to be variable. Regards, Malcolm
On Mon, 26 Jul 2004 11:00:31 +0100, Malcolm Wallace <malcolm.wallace@cs.york.ac.uk> wrote:
While we're discussing changes, is there an overwhelmingly good reason for the use of local quantification beyond making the type signatures simpler? Writing newtype ReadP r a = R ((a -> P r) -> P r) (like in ContT) would make ReadP completely Haskell98 as far as I can tell.
I think you'll find that without the local universal quantifier, you cannot make ReadP a (useful) instance of Monad, because your 'r' parameter would be fixed across >>=, whereas it really needs to be variable.
Uhh. But it works for ContT, so why not for ReadP? The only point time you have to fix the r is when you want to "run" the parser, all other parsers will be polymorphic in r: parseFoo :: ReadP r Foo parseBar :: ReadP r Bar readP_to_S :: ReadP a a -> ReadS a I do exactly this in the package description parsing code of Cabal (using a locally hacked ReadP, Cabal really must be H98...), and it works just fine. /Martin
Martin Sjögren <msjogren@gmail.com> writes:
I think you'll find that without the local universal quantifier, you cannot make ReadP a (useful) instance of Monad, because your 'r' parameter would be fixed across >>=, whereas it really needs to be variable.
Uhh. But it works for ContT, so why not for ReadP? The only point time you have to fix the r is when you want to "run" the parser, all other parsers will be polymorphic in r:
OK, cool. If you can successfully convert ReadP to Haskell'98, we'd all be delighted. But Koen and Simon PJ are the people most likely to be able to give relevant comment on whether any subtle properties will be lost. Regards, Malcolm
participants (5)
-
Daan Leijen -
John Meacham -
Malcolm Wallace -
Martin Sjögren -
Simon Peyton-Jones