Type signatures for nested parameterized rules

[PhilThomas]

This pull request adds support for type signatures on nested parameterized rules.

Since type signatures can now depend on the types of other rules, it first builds an array of ShowS functions that generate typenames given an environment that maps names to types. The array is built in the M monad, so that errors can be reported. Then, a new array of actual type names is built by applying the ShowS functions to the array we are constructing (tying a knot)! The type dependencies should form a DAG, and not a general graph, so no cycles can occur, and the algorithm will terminate. The new array maps both terminals and non-terminals to their respective types; however, terminals are always mapped to the token type, so any token that uses a $$ will yield the wrong type.

[erikd]

You may want to rebase against master and "git push -f". That will get these commits tested with the new .travis.yml file which does much more thorough testing than the old one.

[PhilThomas]

Very cool! I took the opportunity to clean up a little too. Should be good to go now.

[PhilThomas]

I found an issue with ProduceGLRCode.mkDecodeUtils. The types of two elements in seminfo may appear to be different when compared as strings, even though they may be equivalent to Haskell. For instance [Maybe (Token)] and [Maybe Token] are not equal strings, but they do represent equivalent types. Having different string representations of the same type causes mkDecodeUtils to create separate instances of TreeDecode for equivalent types, making ghc very unhappy. I suppose that this was always a potential problem, but previously, the user was in complete control of the String form of all types, and could be counted upon to make sure that equivalent types had the same representation. However, when types are generated for parameterized rules, unnecessary parentheses are added in case they are needed, causing the string representations to mismatch (unless the user also adds parentheses to match).

Should happy parse the types and manipulate them as ASTs, something like this:

module Main where

import Language.Haskell.Exts
import Data.Generics

normalizeType :: Data l
              => [(String, Type l)]   -- type var env
              -> Type l               -- input type
              -> ParseResult (Type l) -- normalized type in an error monad
normalizeType env = everywhereM $ mkM f where
  f t = case t of
    TyVar l (Ident _ s) -> -- substitute type variables
      case lookup s env of
        Nothing -> fail $ "Unknown type variable '" ++ s ++ "'"
        Just t' -> return t'
    TyParen _ t1 -> return t1 -- remove parens
    _ -> return t -- preserve everything else

main :: IO ()
main =
  let r = do { t <- parseType "[(Maybe a)]"
             ; a <- parseType "Token Int"
             ; normalizeType [("a", a)] t
             }
  in case r of
    ParseFailed _ err -> putStrLn err
    ParseOk t -> putStrLn $ prettyPrint t -- prints "[Maybe (Token Int)]"

Unfortunately, this would make happy depend on haskell-src-exts (which depends on happy!) and syb...