On Thu, 7 Feb 2008, Albert Y. C. Lai wrote:
> Is it good or bad to add:
>
> instance (MonadIO m) => MonadIO (ParsecT s u m)
>
I don't see any reason not to add it - it's not as if we can prevent
people lifting to IO! Good catch.
--
[EMAIL PROTECTED]
A problem that's all in your head is stil
Is it good or bad to add:
instance (MonadIO m) => MonadIO (ParsecT s u m)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Probably a weird idea but could this be useful?
class (Monad m) => Stream s m t | s -> t where
uncons :: s -> m (m (t,s))
for example:
instance (Monad m) => Stream [t] m t where
uncons [] = return $ fail "uncons []"
uncons (t:ts) = return $ return (t,ts)
One small advantage is t
On Feb 4, 2008 9:11 PM, Philippa Cowderoy <[EMAIL PROTECTED]> wrote:
> It's a necessary part of how Parsec works - both the Consumed and the
> Reply depend on the input stream, which is now generated from within the
> base monad. The Consumed result is evaluated in advance of the Reply, so
> keepin
On Sun, 3 Feb 2008, Antoine Latter wrote:
> Another picky nit:
>
> The monad transformer type is defined as such:
>
> > data ParsecT s u m a
> > = ParsecT { runParsecT :: State s u -> m (Consumed (m (Reply s u
a))) }
>
> with the Consumed and reply types as:
>
> > data Consumed a = Consumed a
Another picky nit:
The monad transformer type is defined as such:
> data ParsecT s u m a
> = ParsecT { runParsecT :: State s u -> m (Consumed (m (Reply s u a))) }
with the Consumed and reply types as:
> data Consumed a = Consumed a
> | Empty !a
> data Reply s u a = Ok !a
On Sat, 2008-02-02 at 20:43 -0600, Antoine Latter wrote:
> On Feb 2, 2008 5:28 PM, Antoine Latter <[EMAIL PROTECTED]> wrote:
> > I'm not a fan of parameterizing the "Stream" class over the monad parameter
> > `m':
> >
> > > class Stream s m t | s -> t where
> > >uncons :: s -> m (Maybe (t,s))
On Sat, 2 Feb 2008, Antoine Latter wrote:
> To expand on this point, side-effect instances of Stream don't play
> nice with the backtracking in Text.Parsec.Prim.try:
>
> > import Text.Parsec
> > import Text.Parsec.Prim
> > import System.IO
> > import Control.Monad
>
> > type Parser a = (Stream s
On Feb 2, 2008 5:28 PM, Antoine Latter <[EMAIL PROTECTED]> wrote:
> I'm not a fan of parameterizing the "Stream" class over the monad parameter
> `m':
>
> > class Stream s m t | s -> t where
> >uncons :: s -> m (Maybe (t,s))
>
> which leads to instance declarations like so:
>
> > instance Mona
On Sat, 2 Feb 2008, Antoine Latter wrote:
> I'm not a fan of parameterizing the "Stream" class over the monad
> parameter `m':
> I looked through the sources and I didn't see anywhere where this
> parameterization gained anything. As a proof of this I did a
> mechanical re-write removing the cl
I'm not a fan of parameterizing the "Stream" class over the monad parameter `m':
> class Stream s m t | s -> t where
>uncons :: s -> m (Maybe (t,s))
which leads to instance declarations like so:
> instance Monad m => Stream [tok] m tok where
> uncons [] = return $ Nothing
> uncon
[Now with 100% more correct darcs get URLs.]
I'm currently getting Paolo Martini's Google Summer of Code project, an
updated version of Parsec, into a releasable state, and I will be
maintaining it for at least a while.
Paolo's major additions are:
* The Parser monad has been generalized into
12 matches
Mail list logo