You could do this, I believe, but it'd make ReadP less covenient for most users, because they'd have to add these redundant (and inexplicable) 'r' parameters. By "inexplicable" I mean that given a value p::ReadP r a we can say that p is a parser that parses some input, returning a value of type 'a'... but what's this 'r' thing? Wrapping up a polymorphic fn in a newtype is very standard, even though it is not H98. I'd be pretty reluctant to make this change Simon | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Martin | Sjögren | Sent: 26 July 2004 12:18 | To: libraries@haskell.org | Subject: Re: Combinators for ReadP | | On Mon, 26 Jul 2004 11:00:31 +0100, Malcolm Wallace | 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 | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries