I find it's good for the soul to remember what the do notation is doing for us.
Also I'm with Einstein on "You do not really understand something
unless you can explain it to your grandmother" :)
Personally I think (in this instance) your three 'Parser a' functions
read nicer as:
primary = (identifier >>= (return . PrimaryIdentifier)) <|> (stringLiteral >>=
(return . PrimaryLiteral))
identifier = (many1 letter) >>= (return . Identifier)
stringLiteral = (char '\'') >> (manyTill anyChar (char '\'')) >>= (return .
StringLiteral)
Looking at them in this form Tomek's point should seem clear now,
especially when we look at the type signature for liftM:
liftM :: Monad m => (a1 -> r) -> m a1 -> m r
So we can (marginally) shorten down to:
primary = (liftM PrimaryIdentifier identifier) <|> (liftM PrimaryLiteral
stringLiteral)
identifier = liftM Identifier (many1 letter)
stringLiteral = liftM StringLiteral ((char '\'') >> (manyTill anyChar (char
'\'')))
You might like:
http://syntaxfree.wordpress.com/2006/12/12/do-notation-considered-harmful/
Dave,
On 21/06/07, Tomasz Zielonka <[EMAIL PROTECTED]> wrote:
On Thu, Jun 21, 2007 at 03:34:54PM +0930, Levi Stephen wrote:
> Is there a way through combining types/parsers that the double do
> block in primary could be avoided?
>
> I understand it's necessary right now because the parsers identifier
> and stringLiteral return different types, so I can't just write:
>
> >i <- identifier <|> stringLiteral
You can use the fact that (GenParser tok st) is a monad and use liftM:
i <- liftM PrimaryIdentifier identifier <|> liftM PrimaryLiteral
stringLiteral
I often find it convenient to use "choice" instead of <|> for long more
complicated alternatives, for example like this:
primary =
choice
[ do
i <- identifier
return $ PrimaryIdentifier i
, do
l <- stringLiteral
return $ PrimaryLiteral l
]
> So, I'm not sure whether my types need work,
I have a feeling that Identifier and Literal could just be type
synonyms, because newtype's don't seem to be neccesary or beneficial
here. I could be wrong though - after all, I don't know your intentions
and the rest of the program.
Best regards
Tomek
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
