Combinators for ReadP

[Simon Peyton-Jones]

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 at haskell.org [mailto:libraries-bounces at haskell.org] On Behalf Of Martin
| Sjögren
| Sent: 26 July 2004 12:18
| To: libraries at haskell.org
| Subject: Re: Combinators for ReadP
| 
| On Mon, 26 Jul 2004 11:00:31 +0100, Malcolm Wallace
| <malcolm.wallace at 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
| _______________________________________________
| Libraries mailing list
| Libraries at haskell.org
| http://www.haskell.org/mailman/listinfo/libraries