Malte Milatz wrote:
> If not using unsafePerformIO, which is usually not what we want, the
> monad m in question must incorporate IO. That is, it could be defined
> something like (say we want a parser with state):
>
> newtype IOParser tok s a
> = IOParser (s -> [tok] -> IO (s,a))
>
> You can then define liftIO without “taking apart” the IO value;
> instead you put liftIO's IO action (IO a) into IOParser's IO action
> (IO (s,a)). Parsec does not define any such parser, though, so
> there's nothing for which you may define an instance of MonadIO.
>
> Malte
I'm making (or have "made") such a thing, although not necessarily atop
IO, atop any monad that provides certain stream-like functionality.
It's kind of done, but not really.
$ darcs get http://samuelhughes.com/darcs/partran/
That is virtually completely untested and has not been proven correct
either.
Also, whatever documentation there is has probably accidentally been
copied and pasted from Parsec's (except for the documentation of
Stream.hs). Some of the unthinkingly done translations of the files
found in Parsec's hierarchy seem to be idiomatically immoral. (Token.hs
comes to mind. Something went wrong with functional dependencies and
avoiding things like breaking the coverage condition/undecidable
instances and it hurts. Maybe somebody could tell me what I'm doing
wrong.) Also, some functions and definitions of things might be
appropriately moved around, and you'll probably end up having to import
more than you'd like to.
"Text.ParserCombinators.ParTran.Parsec" /might/ currently contain a
correct simulation of "Text.ParserCombinators.Parsec".
- Sam
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
