Q:

Haskell - ambiguous class function

I'm making console program where I will be heavily working with text menus.  I wrote a class Menu with function choices which returns string of possible menu choices and function parseChoice which convert string entered by the user to menu item. 
data MainMenu = FirstItem | SecondItem

class Menu a where
  choices :: String -- ERROR HERE
  parseChoice :: String -> Maybe a

instance Menu MainMenu where
  choices = "1) first choice\n2) second choice"
  parseChoice "1" = Just FirstItem
  parseChoice "2" = Just SecondItem
  parseChoice _ = Nothing

getMenuItem :: Menu a => IO a
getMenuItem = do
  putStrLn choices -- ERROR HERE
  choice <- getLine
  case parseChoice choice of
    Just item -> return item
    Nothing -> getMenuItem

main :: IO ()
main = (getMenuItem :: IO MainMenu) >> return ()

Unfortunatelly, I'm getting following error
• Could not deduce (Menu a0) arising from a use of ‘choices’
  from the context: Menu a
    bound by the type signature for:
               getMenuItem :: Menu a => IO a
    at [removed].hs:15:1-29
  The type variable ‘a0’ is ambiguous
  These potential instance exist:
    instance Menu MainMenu
      -- Defined at [removed].hs:9:10
• In the first argument of ‘putStrLn’, namely ‘choices’
  In a stmt of a 'do' block: putStrLn choices
  In the expression:
    do { putStrLn choices;
         choice <- getLine;
         case parseChoice choice of {
           Just item -> return item
           Nothing -> getMenuItem } }

I know the error occurs because Haskell don't know which choices function use.  I tried something like putStrLn (choices :: Menu a) but without success. 
Question are: Where is the problem (and how to fix it)?  Should I use different approach (which)? 
And please be polite, I'm Haskell newbie. 
Thank you. 

A:

@porges is correct about why this happens, the compiler simply doesn't have enough information to know which instance of the typeclass choices would be coming from.   Instead, you can try tagging it with a phantom type:
data Choices a = Choices String

class Menu a where
    choices :: Choices a
    parseChoices :: String -> Maybe a

This alone won't quite be enough, you'll need to annotate the type where ever you use choices:
putStrLn (choices :: Choices a)

This isn't really ideal, though.   An alternative is to ditch the typeclass approach altogether and stick with a basic data type:
data Menu a = Menu
    { choices :: String
    , parseChoices :: String -> Maybe a
    }

Then you can do
data MainMenu = FirstItem | SecondItem

mainMenu :: Menu MainMenu
mainMenu = Menu _choices _parseChoices where
    _choices = "1) first choice\n2) second choice"
    _parseChoices "1" = Just FirstItem
    _parsechoices "2" = Just SecondItem
    _parseChoices _   = Nothing

And finally
getMenuItem :: Menu a -> IO a
getMenuItem menu@(Menu choices parseChoices) = do
    putStrLn choices
    choice <- getLine
    case parseChoice choice of
        Just item -> return item
        Nothing -> getMenuItem menu

main :: IO ()
main = (getMenuItem mainMenu) >> return ()

A:

The problem is that the line putStrLn choices is inherently ambiguous.  When multiple instances of the class Menu are available, it might mean to print any of them.  You might intend, in your mind, to use the instance made available by the Menu a => constaint, but another programmer could want to avoid that and pick the Menu MainMenu instance, disregarding a.
One option would be to avoid typeclasses.  This is probably the saner, simpler, and most effective way to go.  Just make Menu a type like
data Menu = Menu { choices :: String , ... }

and pass a value of that type around, manually. 
Assuming we want to stick with the typeclass for some reason, we can disambiguate the culprit line by changing the type of choices as follows:
{-# LANGUAGE ScopedTypeVariables #-}
import Data. Proxy

class Menu a where
   choices :: proxy a -> String
   ...

getMenuItem :: forall a. Menu a => IO a
getMenuItem = do
  putStrLn (choices (Proxy :: Proxy a))
  ...

The additional proxy argument has a dummy value.  At runtime it carries no information, but at compile time it allows the compiler to disambiguate.     
Alternatively, with some other newer GHC extensions one can use some code which is closer to the original one
{-# LANGUAGE ScopedTypeVariables, AllowAmbiguousTypes, TypeApplications #-}

class Menu a where
   choices :: String
   ...

getMenuItem :: forall a. Menu a => IO a
getMenuItem = do
  putStrLn (choices @ a)
  ...

This quite a new style, but chances are that this will be used a lot in the future.  This is because it is simpler than passing proxies around.  Even type theorists should appreciate explicit type arguments, which are commonly found in many typed lambda calculi.