Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Text.XML.Stream.Parse.choose seems to be awkward to use. #72

seanparsons opened this Issue Jan 31, 2016 · 1 comment


None yet
2 participants
Copy link

seanparsons commented Jan 31, 2016

The choose method seems to be quite troublesome to use:

getTagContent :: Name -> Consumer Event IO (Maybe (Name, Text))
getTagContent tag = fmap (\content -> fmap (\c -> (tag, c)) content) $ tagIgnoreAttrs tag content

getTagsContent :: [Name] -> Consumer Event IO (Maybe (Name, Text))
getTagsContent tags = choose $ (fmap getTagContent tags)

The compile fails with:

    Couldn't match type ‘ConduitM Event o0 IO (Maybe (Name, Text))’
                   with ‘forall o1. ConduitM Event o1 IO (Maybe (Name, Text))’
    Expected type: Name -> Consumer Event IO (Maybe (Name, Text))
      Actual type: Name -> ConduitM Event o0 IO (Maybe (Name, Text))
    In the first argument of ‘fmap’, namely ‘getTagContent’
    In the second argument of ‘($)’, namely ‘(fmap getTagContent tags)’

See also (someone else having this issue):

Asking in #haskell-beginners on Freenode there was a suggestion that the forall in the expansion of Consumer was at the root of this, which seems to make sense, but I've been unable to determine why. Removing the type definition has no material effect on the error either.


This comment has been minimized.

Copy link

k0ral commented Jan 31, 2016

It boils down to the distinction between [forall a. a] and forall a. [a]. As I don't feel confident to explain it myself, here is an article on the topic.
The choose combinator is impacted due to its signature enforcing a [forall a. a] pattern, but any other wrapping around Consumer i m a may result in the same error. That's why I personally always use the slightly more verbose ConduitM i o m a in signatures, so that the forall keyword is implicitly moved to top-level, which is what I want most of the time.

@snoyberg snoyberg closed this in 113b982 Jan 31, 2016

snoyberg added a commit that referenced this issue Jan 31, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.