RE: newbie: running a state transformer in context of a state rea der
Marcin, thanks for your help. to implement the lift functionality i added these well known definitions: class (Monad m, Monad (t m)) => TransMonad t m where lift :: m a -> t m a instance (Monad m, Monad (State s m)) => TransMonad (State s) m where lift m = ST (\s -> m >>= (\a -> return (a,s))) but my lookahead function lookahead p = do { s <- fetch ; lift (evalState p s) } is typed as lookahead :: State MyState Maybe a -> State MyState Maybe (a,MyState) but i need lookahead :: State MyState Maybe a -> State MyState Maybe a apparently, the (>>=) and return used in the definition of lift above are for the monad (State s m), and not monad m... everything works if i do not use the TransMonad class, but define lift manually as: lift :: Parser a -> Parser a lift m = ST (\s -> unST m s >>= (\(a,_) -> return (a,s))) but this looks like a special case of the lift above, except the right hand side of 'bind' is executed in the right context. i am still missing something konst -----Original Message----- From: Marcin 'Qrczak' Kowalczyk [mailto:qrczak@knm.org.pl] Sent: Tuesday, February 20, 2001 10:17 AM To: haskell-cafe@haskell.org Subject: Re: newbie: running a state transformer in context of a state reader Mon, 19 Feb 2001 18:07:17 -0800, Konst Sushenko <konsu@microsoft.com> pisze:
now i am curious if it is possible to run the given parser (state transformer) in a context of a state reader somehow, so as the state gets preserved automatically. something that would let me omit the calls to fetch and set methods.
It should be possible to do something like this: lookahead:: Parser a -> Parser a lookahead p = do { s <- fetch ; lift (evalState p s) } where evalState :: Monad m => State s m a -> s -> m a lift :: Monad m => m a -> State s m a are functions which should be available or implementable in a monad transformer framework. I don't have the Hutton/Meijer's paper at hand so I don't know if they provided them and under which names. Such functions are provided e.g. in the framework provided with ghc (by Andy Gill, inspired by Mark P Jones' paper "Functional Programming with Overloading and Higher-Order Polymorphism"). This definition of lookahead uses a separate state transformer thread instead of making changes in place and undoing them later. I don't think that it could make sense to convert a state transformer to a state reader by replacing its internals, because p does want to transform the state locally; a value of type Parser a represents a state transformation. The changes must be isolated from the main parser, but they must happen in some context. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTEPCZA QRCZAK _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Tue, 20 Feb 2001 17:52:33 -0800, Konst Sushenko <konsu@microsoft.com> pisze:
lookahead p = do { s <- fetch ; lift (evalState p s) }
is typed as
lookahead:: State MyState Maybe a -> State MyState Maybe (a,MyState)
but i need
lookahead:: State MyState Maybe a -> State MyState Maybe a
myEvalState = liftM fst yourEvalState Andy Gill's monadic modules provide evalState as a wrapper for runState, which throws away the state component returned. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
participants (2)
-
Konst Sushenko -
qrczak@knm.org.pl