diff --git a/doc.diff b/doc.diff index e69de29..6412e44 100644 --- a/doc.diff +++ b/doc.diff @@ -0,0 +1,7417 @@ +original のみに存在: 7.10.1-notes.xml +original のみに存在: 7.10.2-notes.xml +original のみに存在: 7.10.3-notes.xml +7.8.2-original のみに存在: 7.8.1-notes.xml +7.8.2-original のみに存在: 7.8.2-notes.xml +diff -urd 7.8.2-original/bugs.xml original/bugs.xml +--- 7.8.2-original/bugs.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/bugs.xml 2016-04-09 21:36:11.395998334 +0900 +@@ -71,7 +71,7 @@ + + + main = do args <- getArgs +- if null args then return [] else do ++ if null args then return [] else do + ps <- mapM process args + mapM print ps + +@@ -101,13 +101,25 @@ + + (let x = 42 in x == 42 == True) + ++ ++ ++ The Haskell Report allows you to put a unary ++ - preceding certain expressions headed by ++ keywords, allowing constructs like - case x of ++ ... or - do { ... }. GHC does ++ not allow this. Instead, unary - is ++ allowed before only expressions that could potentially ++ be applied as a function. ++ ++ ++ + + + + + Expressions and patterns + +- In its default mode, GHC makes some programs slightly more defined ++ In its default mode, GHC makes some programs slightly more defined + than they should be. For example, consider + + f :: [a] -> b -> b +@@ -291,7 +303,17 @@ + if you get stuck on it. + + +- ++ ++ splitAt semantics ++ Data.List.splitAt is stricter than specified in the ++ Report. Specifically, the Report specifies that ++splitAt n xs = (take n xs, drop n xs) ++ which implies that ++splitAt undefined undefined = (undefined, undefined) ++ but GHC's implementation is strict in its first argument, so ++splitAt undefined [] = undefined ++ ++ + + Reading integers + +@@ -542,6 +564,14 @@ + + + ++ ++ There is known to be maleficent interactions between weak ++ references and laziness. Particularly, it has been observed that placing a thunk ++ containing a reference to a weak reference inside of another weak reference may ++ cause runtime crashes. See Trac #11108 ++ for details. ++ + + + +@@ -577,17 +607,6 @@ + your package into two or more .o's, along the lines of + how the "base" package does it. + +- +- +- +- GHCi does not keep careful track of what instance +- declarations are 'in scope' if they come from other +- packages. Instead, all instance declarations that GHC has +- seen in other packages are all available at the prompt, +- whether or not the instance really ought to be in visible +- given the current set of modules in scope. +- +- + + + +diff -urd 7.8.2-original/codegens.xml original/codegens.xml +--- 7.8.2-original/codegens.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/codegens.xml 2016-04-09 21:36:11.395998334 +0900 +@@ -32,14 +32,14 @@ + much faster code. This is especially true for numeric, array heavy + code using packages like vector. The penalty is a significant increase in + compilation times. Select the LLVM backend with the +- flag. Currently LLVM 2.8 and +- later are supported. ++ flag. Currently only LLVM 3.5 ++ is supported. + + + You must install and have LLVM available on your PATH for the LLVM + code generator to work. Specifically GHC needs to be able to call the +- optand llc tools. Secondly, if you +- are running Mac OS X with LLVM 3.0 or greater then ++ opt and llc tools. Secondly, if you ++ are running Mac OS X with LLVM 3.5 or greater then + you also need the Clang c + compiler compiler available on your PATH. + +@@ -54,7 +54,7 @@ + order to use the LLVM based code generator, you should install + the Homebrew +- package manager for OS X. Alternatively you can download ++ package manager for OS X and then install LLVM 3.5. Alternatively you can download + binaries for LLVM and Clang from here. + +diff -urd 7.8.2-original/debugging.xml original/debugging.xml +--- 7.8.2-original/debugging.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/debugging.xml 2016-04-09 21:36:11.394998369 +0900 +@@ -182,16 +182,6 @@ + + + +- : +- +- +- +- CPR analyser output +- +- +- +- +- + : + + +@@ -262,16 +252,6 @@ + + + +- : +- +- +- +- flattened Abstract C +- +- +- +- +- + : + + +@@ -335,17 +315,6 @@ + + + +- +- +- : +- +- +- +- Show the output of each run of the simplifier. Used when even +- doesn't cut it. +- +- +- + + + : +diff -urd 7.8.2-original/extending_ghc.xml original/extending_ghc.xml +--- 7.8.2-original/extending_ghc.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/extending_ghc.xml 2016-04-09 21:36:11.393998404 +0900 +@@ -124,9 +124,9 @@ + + Compiler Plugins + +- GHC has the ability to load compiler plugins at compile time. The feature is similar to the one provided by GCC, and allows users to write plugins that can inspect and modify the compilation pipeline, as well as transform and inspect GHC's intermediate language, Core. Plugins are suitable for experimental analysis or optimization, and require no changes to GHC's source code to use. ++ GHC has the ability to load compiler plugins at compile time. The feature is similar to the one provided by GCC, and allows users to write plugins that can adjust the behaviour of the constraint solver, inspect and modify the compilation pipeline, as well as transform and inspect GHC's intermediate language, Core. Plugins are suitable for experimental analysis or optimization, and require no changes to GHC's source code to use. + +- Plugins cannot optimize/inspect C--, nor can they implement things like parser/front-end modifications like GCC. If you feel strongly that any of these restrictions are too onerous, please give the GHC team a shout. ++ Plugins cannot optimize/inspect C--, nor can they implement things like parser/front-end modifications like GCC, apart from limited changes to the constraint solver. If you feel strongly that any of these restrictions are too onerous, please give the GHC team a shout. + + + Using compiler plugins +@@ -183,8 +183,10 @@ + Note carefully the reinitializeGlobals call at the beginning of the installation function. Due to bugs in the windows linker dealing with libghc, this call is necessary to properly ensure compiler plugins have the same global state as GHC at the time of invocation. Without reinitializeGlobals, compiler plugins can crash at runtime because they may require state that hasn't otherwise been initialized. + + In the future, when the linking bugs are fixed, reinitializeGlobals will be deprecated with a warning, and changed to do nothing. +- +- <literal>CoreToDo</literal> in more detail ++ ++ ++ ++ Core plugins in more detail + + CoreToDo is effectively a data type that describes all the kinds of optimization passes GHC does on Core. There are passes for simplification, CSE, vectorisation, etc. There is a specific case for plugins, CoreDoPluginPass :: String -> PluginPass -> CoreToDo which should be what you always use when inserting your own pass into the pipeline. The first parameter is the name of the plugin, and the second is the pass you wish to insert. + +@@ -200,7 +202,6 @@ + + + is certainly valid, but also certainly not what anyone really wants. +- + + + Manipulating bindings +@@ -226,8 +227,8 @@ + return (CoreDoPluginPass "Say name" pass : todo) + + pass :: ModGuts -> CoreM ModGuts +-pass = do dflags <- getDynFlags +- bindsOnlyPass (mapM (printBind dflags)) ++pass guts = do dflags <- getDynFlags ++ bindsOnlyPass (mapM (printBind dflags)) guts + where printBind :: DynFlags -> CoreBind -> CoreM CoreBind + printBind dflags bndr@(NonRec b _) = do + putMsgS $ "Non-recursive binding named " ++ showSDoc dflags (ppr b) +@@ -283,6 +284,60 @@ + + + ++ ++ Typechecker plugins ++ ++ In addition to Core plugins, GHC has experimental support for typechecker plugins, which allow the behaviour of the constraint solver to be modified. For example, they make it possible to interface the compiler to an SMT solver, in order to support a richer theory of type-level arithmetic expressions than the theory built into GHC (see ). ++ ++ The Plugin type has a field tcPlugin of type [CommandLineOption] -> Maybe TcPlugin, where the TcPlugin type is defined thus: ++ ++ ++data TcPlugin = forall s . TcPlugin ++ { tcPluginInit :: TcPluginM s ++ , tcPluginSolve :: s -> TcPluginSolver ++ , tcPluginStop :: s -> TcPluginM () ++ } ++ ++type TcPluginSolver = [Ct] -> [Ct] -> [Ct] -> TcPluginM TcPluginResult ++ ++data TcPluginResult = TcPluginContradiction [Ct] | TcPluginOk [(EvTerm,Ct)] [Ct] ++ ++ ++ (The details of this representation are subject to change as we gain more experience writing typechecker plugins. It should not be assumed to be stable between GHC releases.) ++ ++ The basic idea is as follows: ++ ++ When type checking a module, GHC calls tcPluginInit once before constraint solving starts. This allows the plugin to look things up in the context, initialise mutable state or open a connection to an external process (e.g. an external SMT solver). The plugin can return a result of any type it likes, and the result will be passed to the other two fields. ++ During constraint solving, GHC repeatedly calls tcPluginSolve. This function is provided with the current set of constraints, and should return a TcPluginResult that indicates whether a contradiction was found or progress was made. If the plugin solver makes progress, GHC will re-start the constraint solving pipeline, looping until a fixed point is reached. ++ Finally, GHC calls tcPluginStop after constraint solving is finished, allowing the plugin to dispose of any resources it has allocated (e.g. terminating the SMT solver process). ++ ++ ++ ++ Plugin code runs in the TcPluginM monad, which provides a restricted interface to GHC API functionality that is relevant for typechecker plugins, including IO and reading the environment. If you need functionality that is not exposed in the TcPluginM module, you can use unsafeTcPluginTcM :: TcM a -> TcPluginM a, but are encouraged to contact the GHC team to suggest additions to the interface. Note that TcPluginM can perform arbitrary IO via tcPluginIO :: IO a -> TcPluginM a, although some care must be taken with side effects (particularly in tcPluginSolve). In general, it is up to the plugin author to make sure that any IO they do is safe. ++ ++ ++ ++ Constraint solving with plugins ++ ++ The key component of a typechecker plugin is a function of type TcPluginSolver, like this: ++ ++ ++solve :: [Ct] -> [Ct] -> [Ct] -> TcPluginM TcPluginResult ++solve givens deriveds wanteds = ... ++ ++ ++ This function will be invoked at two points in the constraint solving process: after simplification of given constraints, and after unflattening of wanted constraints. The two phases can be distinguished because the deriveds and wanteds will be empty in the first case. In each case, the plugin should either ++ ++ return TcPluginContradiction with a list of impossible constraints (which must be a subset of those passed in), so they can be turned into errors; or ++ return TcPluginOk with lists of solved and new constraints (the former must be a subset of those passed in and must be supplied with corresponding evidence terms). ++ ++ If the plugin cannot make any progress, it should return TcPluginOk [] []. Otherwise, if there were any new constraints, the main constraint solver will be re-invoked to simplify them, then the plugin will be invoked again. The plugin is responsible for making sure that this process eventually terminates. ++ ++ Plugins are provided with all available constraints (including equalities and typeclass constraints), but it is easy for them to discard those that are not relevant to their domain, because they need return only those constraints for which they have made progress (either by solving or contradicting them). ++ ++ Constraints that have been solved by the plugin must be provided with evidence in the form of an EvTerm of the type of the constraint. This evidence is ignored for given and derived constraints, which GHC "solves" simply by discarding them; typically this is used when they are uninformative (e.g. reflexive equations). For wanted constraints, the evidence will form part of the Core term that is generated after typechecking, and can be checked by . It is possible for the plugin to create equality axioms for use in evidence terms, but GHC does not check their consistency, and inconsistent axiom sets may lead to segfaults or other runtime misbehaviour. ++ ++ + + + +7.8.2-original のみに存在: external_core.xml +diff -urd 7.8.2-original/ffi-chap.xml original/ffi-chap.xml +--- 7.8.2-original/ffi-chap.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/ffi-chap.xml 2016-04-09 21:36:11.395998334 +0900 +@@ -110,7 +110,7 @@ + + + foreign import ccall interruptible +- "sleep" :: CUint -> IO CUint ++ "sleep" sleepBlock :: CUint -> IO CUint + + + interruptible behaves exactly as +diff -urd 7.8.2-original/flags.xml original/flags.xml +--- 7.8.2-original/flags.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/flags.xml 2016-04-09 21:36:11.394998369 +0900 +@@ -56,13 +56,13 @@ + + size + Set the minimum heap size to size +- static ++ dynamic + - + + + + Summarise timing stats for GHC (same as +RTS -tstderr) +- static ++ dynamic + - + + +@@ -209,14 +209,14 @@ + + + +- Do not link +- dynamic ++ Stop after generating object (.o) file ++ mode + - + + + suffix + Override default behaviour for source files +- static ++ dynamic + - + + +@@ -401,13 +401,13 @@ + dir1:dir2:... + add dir, + dir2, etc. to import path +- static/:set ++ dynamic/:set + - + + + + Empty the import directory list +- static/:set ++ dynamic/:set + - + + +@@ -518,18 +518,18 @@ + - + + +- +- Break on any exception thrown +- dynamic +- +- +- + + Break on uncaught exceptions and errors + dynamic + + + ++ ++ Break on any exception thrown ++ dynamic ++ ++ ++ + + Set the number of entries GHCi keeps for :history + dynamic +@@ -590,69 +590,69 @@ + + + +- P ++ P + Compile to be part of package P +- static ++ dynamic + - + + + P + Expose package P +- static/:set ++ dynamic/:set + - + + + + Hide all packages by default +- static ++ dynamic + - + + + name + Hide package P +- static/:set ++ dynamic/:set + - + + + name + Ignore package P +- static/:set ++ dynamic/:set + - + + + file + Add file to the package db stack. +- static ++ dynamic + - + + + + Clear the package db stack. +- static ++ dynamic + - + + + + Remove the global package db from the stack. +- static ++ dynamic + - + + + + Add the global package db to the stack. +- static ++ dynamic + - + + + + Remove the user's package db from the stack. +- static ++ dynamic + - + + + + Add the user's package db to the stack. +- static ++ dynamic + - + + +@@ -665,20 +665,20 @@ + P + Expose package P and set it to be + trusted +- static/:set ++ dynamic/:set + - + + + P + Expose package P and set it to be + distrusted +- static/:set ++ dynamic/:set + - + + + + Distrust all packages by default +- static/:set ++ dynamic/:set + - + + +@@ -691,7 +691,8 @@ + + Language options can be enabled either by a command-line option + , or by a {-# LANGUAGE blah #-} +- pragma in the file itself. See ++ pragma in the file itself. See . Some ++ options are enabled using flags. + + + +@@ -705,6 +706,12 @@ + + + ++ n ++ set the limit for type-class context reduction. Default is 100. ++ dynamic ++ ++ ++ + + Deprecated. Enable most language extensions; see for exactly which ones. + dynamic +@@ -717,13 +724,13 @@ + + + +- n +- set the limit for context reduction. Default is 20. ++ ++ Enable Safe Haskell trusted package requirement for trustworthy modules. + dynamic +- ++ + + +- n ++ n + set the limit for type function reductions. Default is 200. + dynamic + +@@ -745,71 +752,182 @@ + + + +- Automatically derive Typeable instances for every datatype and type class declaration. ++ As of GHC 7.10, this option is not needed, and should ++ not be used. Automatically derive Typeable instances for every datatype and type class declaration. + Implies . + dynamic + + + ++ ++ Enable bang patterns. ++ dynamic ++ ++ ++ ++ ++ Enable support for binary literals. ++ dynamic ++ ++ ++ ++ ++ Enable the CAPI calling convention. ++ dynamic ++ ++ ++ ++ ++ Enable constrained class methods. ++ dynamic ++ ++ ++ + + Enable a kind of constraints. + dynamic + + + ++ ++ Enable the C preprocessor. ++ dynamic ++ ++ ++ + + Enable datatype promotion. + dynamic + + + ++ ++ Enable default signatures. ++ dynamic ++ ++ ++ ++ ++ Enable deriving for any ++ class. ++ dynamic ++ ++ ++ + +- Enable deriving for the Data and Typeable classes. ++ Enable deriving for the Data class. ++ Implied by . + dynamic + + + ++ ++ Enable deriving for the Functor class. ++ Implied by . ++ dynamic ++ ++ ++ ++ ++ Enable deriving for the Foldable class. ++ Implied by . ++ dynamic ++ ++ ++ + + Enable deriving for the Generic class. + dynamic + + + +- +- Enable newtype deriving. ++ ++ Enable deriving for the Traversable class. ++ Implies and . + dynamic +- ++ + + + +- Enable record +- field disambiguation ++ Enable record field disambiguation. ++ Implied by . + dynamic + + + + +- Allow empty case alternatives +- ++ Allow empty case alternatives. + dynamic + + + ++ ++ Enable empty data declarations. ++ dynamic ++ ++ ++ ++ ++ Enable existential quantification. ++ dynamic ++ ++ ++ ++ ++ Enable explicit universal quantification. ++ Implied by , ++ , ++ and ++ . ++ ++ dynamic ++ ++ ++ ++ ++ Enable using the keyword type to specify the namespace of ++ entries in imports and exports (). ++ Implied by and . ++ dynamic ++ ++ ++ + +- Use GHCi's extended default rules in a normal module ++ Use GHCi's extended default rules in a normal module. + dynamic + + + ++ ++ Enable flexible contexts. ++ Implied by . ++ dynamic ++ ++ ++ ++ ++ Enable flexible instances. ++ Implies . Implied by . ++ dynamic ++ ++ ++ + + Enable foreign function interface. + dynamic + + + ++ ++ Enable functional dependencies. ++ Implies . ++ dynamic ++ ++ ++ + + Enable generalised algebraic data types. +- ++ Implies and . + dynamic + + +@@ -821,6 +939,12 @@ + + + ++ ++ Enable newtype deriving. ++ dynamic ++ ++ ++ + + Deprecated, does nothing. No longer enables generic classes. + See also GHC's support for +@@ -830,103 +954,74 @@ + + + +- Enable Implicit Parameters. ++ Enable Implicit Parameters. ++ Implies and . + dynamic + + + + +- Don't implicitly import Prelude ++ Don't implicitly import Prelude. ++ Implied by . + dynamic + + + +- +- Enable incoherent instances. +- Implies +- dynamic +- +- +- +- +- Disable the monomorphism restriction +- dynamic +- +- +- +- +- Enable support for negative literals +- dynamic +- +- +- +- +- Disable support for n+k patterns +- dynamic +- +- +- +- +- Enable support for 'fractional' integer literals +- dynamic +- +- +- +- +- Enable overlapping instances ++ ++ Enable impredicative types. ++ Implies . + dynamic +- ++ + + +- +- Enable overloaded lists. +- ++ ++ Enable incoherent instances. ++ Implies . + dynamic +- ++ + + +- +- Enable overloaded string literals. +- ++ ++ Enable instance signatures. + dynamic +- ++ + + +- +- Enable quasiquotation. ++ ++ Enable interruptible FFI. + dynamic +- ++ + + +- +- Relaxed checking for mutually-recursive polymorphic functions ++ ++ Enable kind signatures. ++ Implied by and . + dynamic +- ++ + + +- +- Disable support for traditional record syntax (as supported by Haskell 98) C {f = x} ++ ++ Enable lambda-case expressions. + dynamic +- ++ + + +- +- Enable type families. ++ ++ Enable liberalised type synonyms. + dynamic +- ++ + + +- +- Enable undecidable instances ++ ++ Allow "#" as a postfix modifier on identifiers. + dynamic +- ++ + + +- +- Enable kind polymorphism. +- Implies . ++ ++ Enable monad comprehensions. + dynamic +- ++ + + + +@@ -937,162 +1032,169 @@ + + + +- +- Employ rebindable syntax ++ ++ Disable the monomorphism restriction. + dynamic +- ++ + + +- +- Enable lexically-scoped type variables. +- ++ ++ Enable multi parameter type classes. ++ Implied by . + dynamic +- ++ + + +- +- Enable Template Haskell. ++ ++ Enable multi-way if-expressions. + dynamic +- ++ + + +- +- Enable bang patterns. ++ ++ Enable record puns. + dynamic +- ++ + + +- +- Enable the C preprocessor. ++ ++ Enable named wildcards. + dynamic +- ++ + + +- +- Enable pattern guards. ++ ++ Enable support for negative literals. + dynamic +- ++ + + +- +- Enable view patterns. ++ ++ Disable support for n+k patterns. + dynamic +- ++ + + +- +- Enable unicode syntax. ++ ++ Deprecated, does nothing. nullary (no parameter) type classes are now enabled using . + dynamic +- ++ + + +- +- Allow "#" as a postfix modifier on identifiers. ++ ++ Enable support for 'fractional' integer literals. + dynamic +- ++ + + +- +- Enable explicit universal quantification. +- Implied by , +- , +- , +- +- ++ ++ Enable overlapping instances. + dynamic +- ++ + + +- +- Enable polymorphic components for data constructors. +- dynamic, synonym for +- ++ ++ Enable overloaded lists. ++ ++ dynamic ++ + + +- +- Enable rank-2 types. +- dynamic, synonym for +- ++ ++ Enable overloaded string literals. ++ ++ dynamic ++ + + +- +- Enable rank-N types. ++ ++ Enable package-qualified imports. + dynamic +- ++ + + +- +- Enable impredicative types. ++ ++ Enable parallel arrays. ++ Implies . + dynamic +- ++ + + +- +- Enable existential quantification. ++ ++ Enable parallel list comprehensions. ++ Implied by . + dynamic +- ++ + + +- +- Enable kind signatures. ++ ++ Enable partial type signatures. + dynamic +- ++ + + +- +- Enable empty data declarations. ++ ++ Enable pattern guards. + dynamic +- ++ + + +- +- Enable parallel list comprehensions. ++ ++ Enable pattern synonyms. + dynamic +- ++ + + +- +- Enable generalised list comprehensions. ++ ++ Enable kind polymorphism. ++ Implies . + dynamic +- ++ + + +- +- Enable monad comprehensions. +- dynamic +- ++ ++ Enable polymorphic components for data constructors. ++ dynamic, synonym for ++ + + +- +- Enable unlifted FFI types. ++ ++ Enable postfix operators. + dynamic +- ++ + + +- +- Enable interruptible FFI. ++ ++ Enable quasiquotation. + dynamic +- ++ + + +- +- Enable liberalised type synonyms. ++ ++ Enable rank-2 types. ++ dynamic, synonym for ++ ++ ++ ++ ++ Enable rank-N types. ++ Implied by . + dynamic +- ++ + + +- +- Enable type operators. ++ ++ Employ rebindable syntax. ++ Implies . + dynamic +- ++ + + +- +- Enable using the keyword type to specify the namespace of +- entries in imports and exports (). +- Implied by and . ++ ++ Enable record wildcards. ++ Implies . + dynamic +- ++ + + + +@@ -1101,34 +1203,30 @@ + + + +- +- Enable parallel arrays. +- dynamic +- +- +- +- +- Enable record wildcards. ++ ++ (deprecated) Relaxed checking for ++ mutually-recursive polymorphic functions. + dynamic +- ++ + + +- +- Enable record puns. ++ ++ Enable role annotations. + dynamic +- ++ + + +- +- Enable record field disambiguation. ++ ++ Enable the Safe Haskell Safe mode. + dynamic +- ++ + + +- +- Enable unboxed tuples. ++ ++ Enable lexically-scoped type variables. ++ + dynamic +- ++ + + + +@@ -1137,83 +1235,80 @@ + + + +- +- Enable type synonyms in instance heads. +- dynamic +- +- +- +- +- Enable flexible contexts. ++ ++ Enable Template Haskell. + dynamic +- ++ + + +- +- Enable flexible instances. +- Implies ++ ++ Disable support for traditional record syntax (as supported by Haskell 98) C {f = x} + dynamic +- ++ + + +- +- Enable constrained class methods. ++ ++ Enable generalised list comprehensions. + dynamic +- ++ + + +- +- Enable default signatures. ++ ++ Enable the Safe Haskell Trustworthy mode. + dynamic +- ++ + + +- +- Enable multi parameter type classes. ++ ++ Enable tuple sections. + dynamic +- ++ + + +- +- Enable nullary (no parameter) type classes. ++ ++ Enable type families. ++ Implies , ++ and . + dynamic +- ++ + + +- +- Enable functional dependencies. ++ ++ Enable type operators. ++ Implies . + dynamic +- ++ + + +- +- Enable package-qualified imports. ++ ++ Enable type synonyms in instance heads. ++ Implied by . + dynamic +- ++ + + +- +- Enable lambda-case expressions. ++ ++ Enable unboxed tuples. + dynamic +- ++ + + +- +- Enable multi-way if-expressions. ++ ++ Enable undecidable instances. + dynamic +- ++ + + +- +- Enable the Safe Haskell Safe mode. ++ ++ Enable unicode syntax. + dynamic +- ++ + + +- +- Enable the Safe Haskell Trustworthy mode. ++ ++ Enable unlifted FFI types. + dynamic +- ++ + + + +@@ -1222,10 +1317,10 @@ + + + +- +- Enable Safe Haskell trusted package requirement for trustworthy modules. ++ ++ Enable view patterns. + dynamic +- ++ + + + +@@ -1281,12 +1376,29 @@ + + + +- Defer as many type errors as possible until runtime. ++ ++ Turn type errors into warnings, ++ deferring the error until runtime. Implies ++ . ++ + dynamic + + + + ++ ++ ++ Convert typed hole errors ++ into warnings, deferring the ++ error until runtime. Implied by ++ . See also ++ . ++ ++ dynamic ++ ++ ++ ++ + + Make suggestions for mis-spelled names. + dynamic +@@ -1395,6 +1507,13 @@ + + + ++ ++ warn about top-level functions without signatures, only if they are exported. takes precedence over -fwarn-missing-signatures ++ dynamic ++ ++ ++ ++ + + warn about polymorphic local bindings without signatures + dynamic +@@ -1452,6 +1571,13 @@ + + + ++ ++ warn if promoted constructors are not ticked ++ dynamic ++ ++ ++ ++ + + warn about bindings that are unused + dynamic +@@ -1490,7 +1616,10 @@ + + warn if the module being compiled is regarded to be unsafe. + Should be used to check the safety status of modules when using safe +- inference. ++ inference. Works on all module types, even those using explicit ++ Safe Haskell modes (such as ++ ) and so can be used to have the ++ compiler check any assumptions made. + dynamic + + +@@ -1499,7 +1628,21 @@ + + warn if the module being compiled is regarded to be safe. + Should be used to check the safety status of modules when using safe +- inference. ++ inference. Works on all module types, even those using explicit ++ Safe Haskell modes (such as ++ ) and so can be used to have the ++ compiler check any assumptions made. ++ dynamic ++ ++ ++ ++ ++ ++ warn if the module being compiled is marked as ++ but it could instead be marked as ++ , a more informative bound. Can be used to ++ detect once a Safe Haskell bound can be improved as dependencies ++ are updated. + dynamic + + +@@ -1513,18 +1656,49 @@ + + + +- warn on definitions conflicting with the Applicative-Monad Proposal (AMP) ++ (deprecated) warn on definitions conflicting with the Applicative-Monad Proposal (AMP) + dynamic + + + + + +- Enable holes in expressions. ++ ++ Report warnings when typed hole ++ errors are deferred until ++ runtime. See . ++ + dynamic + + + ++ ++ ++ ++ warn about holes in partial type signatures when ++ is enabled. Not ++ applicable when is not ++ enabled, in which case errors are generated for such holes. ++ See . ++ ++ dynamic ++ ++ ++ ++ ++ ++ ++ warn when encountering a request to derive an instance of ++ class Typeable. As of GHC 7.10, such ++ declarations are unnecessary and are ignored by the compiler ++ because GHC has a custom solver for discharging this type of ++ constraint. ++ ++ dynamic ++ ++ ++ ++ + + + +@@ -1547,26 +1721,46 @@ + + + ++ ++ Disable optimisations (default) ++ dynamic + +- Enable default optimisation (level 1) ++ ++ ++ or ++ Enable level 1 optimisations + dynamic + + + +- n +- Set optimisation level n ++ ++ Enable level 2 optimisations + dynamic + + ++ ++ ++ Enable level 2 optimisations, set ++ and . ++ dynamic ++ - ++ + + + + ++ See for a list of optimisations enabled on level 1 and level 2. ++ + + + Individual optimisations + +- These options are described in more detail in . ++ These options are described in more detail in . ++ If a flag is implied by then it is also implied by ++ (unless flag description explicitly says otherwise). ++ If a flag is implied by only then the flag is not ++ implied by and . ++ + + + +@@ -1580,6 +1774,13 @@ + + + ++ ++ Enable call-arity optimisation. Implied by . ++ dynamic ++ ++ ++ ++ + + Enable case-merging. Implied by . + dynamic +@@ -1587,20 +1788,58 @@ + + + ++ ++ Enable Cmm common block elimination. Implied by . ++ dynamic ++ ++ ++ ++ ++ ++ Enable Cmm sinking. Implied by . ++ dynamic ++ ++ ++ ++ ++ ++ Switch off CPR analysis in the demand analyser. ++ static ++ - ++ ++ ++ + +- Turn on common sub-expression elimination. Implied by . ++ Enable common sub-expression elimination. Implied by . + dynamic + + + + ++ ++ Make dictionary-valued expressions seem cheap to the optimiser. ++ dynamic ++ ++ ++ ++ + + Make dictionaries strict +- static ++ dynamic + + + + ++ ++ ++ Use a special demand transformer for dictionary selectors. ++ Always enabled by default. ++ ++ dynamic ++ ++ ++ ++ + + Enable eta-reduction. Implied by . + dynamic +@@ -1609,7 +1848,7 @@ + + + +- Enable lambda eta-reduction ++ Enable lambda eta-expansion. Always enabled by default. + dynamic + + +@@ -1631,24 +1870,17 @@ + + + +- +- Enable vectorisation of nested data parallelism +- dynamic +- +- +- +- +- +- Enable vectorisation avoidance (EXPERIMENTAL) ++ ++ Enable excess intermediate precision + dynamic +- ++ + + + +- +- Enable excess intermediate precision ++ ++ Expose all unfoldings, even for very large or recursive functions. + dynamic +- ++ + + + +@@ -1676,26 +1908,19 @@ + + + +- Ignore assertions in the source ++ Ignore assertions in the source. Implied by . + dynamic + + + + + +- Ignore pragmas in interface files ++ Ignore pragmas in interface files. Implied by only. + dynamic + + + + +- +- Turn saturated self-recursive tail-calls into local jumps in the generated assembly. +- dynamic +- +- +- +- + + Run demand analysis again, at the end of the simplification + pipeline +@@ -1712,27 +1937,72 @@ + + + =n +- Set the size threshold for the liberate-case transformation to n (default: 200) +- static ++ Set the size threshold for the liberate-case transformation to n (default: 2000) ++ dynamis + + + + +- ++ ++ Turn saturated self-recursive tail-calls into local jumps in the generated assembly. ++ Implied by . ++ dynamic ++ ++ ++ ++ ++ =n ++ Set the maximum size of inline array allocations to ++ n bytes (default: 128). GHC ++ will allocate non-pinned arrays of statically known size ++ in the current nursery block if they're no bigger than ++ n bytes, ignoring GC overheap. ++ This value should be quite a bit smaller than the block ++ size (typically: 4096). ++ dynamic ++ - ++ ++ ++ ++ ++ =n ++ ++ Inline memcpy calls if they would generate no more ++ than n pseudo instructions ++ (default: 32). ++ ++ dynamic ++ - ++ ++ ++ ++ ++ =n ++ ++ Inline memset calls if they would generate no more ++ than n pseudo instructions ++ (default: 32). ++ ++ dynamic ++ - ++ ++ ++ ++ + Set the maximum number of bindings to display in type error messages (default 6). + dynamic + + + + +- +- Set the max iterations for the simplifier ++ ++ Set the max iterations for the simplifier (default 4). + dynamic + - + + + +- ++ + If a worker has that many arguments, none will be + unpacked anymore (default: 10) + dynamic +@@ -1762,6 +2032,20 @@ + + + ++ ++ Don't generate interface pragmas. Implied by only. ++ dynamic ++ ++ ++ ++ ++ ++ Omit heap checks when no allocation is being performed. ++ dynamic ++ ++ ++ ++ + + Make GHC be more precise about its treatment of bottom (but see also + ). In particular, GHC will not +@@ -1771,14 +2055,23 @@ + + + +- +- Don't generate interface pragmas ++ ++ Use the graph colouring register allocator for register allocation ++ in the native code generator. Implied by . + dynamic +- ++ + + + +- ++ ++ Use the iterative coalescing graph colouring register allocator ++ in the native code generator. ++ dynamic ++ ++ ++ ++ ++ + Set the number of phases for the simplifier (default 2). + Ignored with . + dynamic +@@ -1800,22 +2093,23 @@ + + + +- =n +- Set the size threshold for the SpecConstr transformation to n (default: 200) +- static +- +- +- +- + =n + Set to n (default: 3) the maximum number of + specialisations that will be created for any one function + by the SpecConstr transformation +- static ++ dynamic + + + + ++ =n ++ Set the size threshold for the SpecConstr transformation ++ to n (default: 2000) ++ dynamic ++ ++ ++ ++ + + Turn on specialisation of overloaded functions. Implied by . + dynamic +@@ -1823,6 +2117,13 @@ + + + ++ ++ Turn on the static argument transformation. ++ dynamic ++ ++ ++ ++ + + Turn on strictness analysis. Implied by . + dynamic +@@ -1830,7 +2131,7 @@ + + + +- =n ++ =n + Run an additional strictness analysis before simplifier + phase n + dynamic +@@ -1838,10 +2139,11 @@ + + + +- +- Turn on the static argument transformation. Implied by . ++ ++ Flatten strict constructor fields with a ++ pointer-sized representation. Implied by . + dynamic +- ++ + + + +@@ -1852,39 +2154,52 @@ + + + +- +- Flatten strict constructor fields with a +- pointer-sized representation ++ ++ Tweak unfolding settings. Default: 750 + dynamic +- ++ - + + + +- +- Tweak unfolding settings ++ ++ Tweak unfolding settings. Default: 30 + dynamic +- ++ - + + + +- +- Tweak unfolding settings ++ ++ Tweak unfolding settings. Default: 60 + dynamic +- ++ - + + + +- +- Tweak unfolding settings ++ ++ Tweak unfolding settings. Default: 1.5 + dynamic +- ++ - + + + +- +- Tweak unfolding settings ++ ++ Tweak unfolding settings. Default: 60 + dynamic +- ++ - ++ ++ ++ ++ ++ Enable vectorisation avoidance. Always enabled by default. ++ dynamic ++ ++ ++ ++ ++ ++ Enable vectorisation of nested data parallelism ++ dynamic ++ + + + +@@ -1911,7 +2226,7 @@ + + + Turn on profiling +- static ++ dynamic + - + + +@@ -1950,7 +2265,7 @@ + + + Turn on ticky-ticky profiling +- static ++ dynamic + - + + +@@ -2104,6 +2419,12 @@ + - + + ++ ++ Always write interface files ++ dynamic ++ - ++ ++ + + Generate byte-code + dynamic +@@ -2160,32 +2481,32 @@ + + + Use dynamic Haskell libraries (if available) +- static ++ dynamic + - + + + + Build dynamic object files as well as static object files during compilation +- static ++ dynamic + - + + + + Set the output path for the dynamically linked objects +- static ++ dynamic + - + + + + Set the output suffix for dynamic object files +- static ++ dynamic + - + + + + Selects one of a number of modes for finding shared + libraries at runtime. +- static ++ dynamic + - + + +@@ -2264,25 +2585,32 @@ + + + Use static Haskell libraries +- static ++ dynamic + - + + + + Use the threaded runtime +- static ++ dynamic + - + + + + Use the debugging runtime +- static ++ dynamic ++ - ++ ++ ++ ++ For linking, this simply implies ; ++ see . ++ dynamic + - + + + + Enable runtime event tracing +- static ++ dynamic + - + + +@@ -2312,6 +2640,15 @@ + dynamic + - + ++ ++ ++ This instructs the linker to add all symbols, not only used ones, to the ++ dynamic symbol table. Currently Linux and Windows/MinGW32 only. ++ This is equivalent to using -optl -rdynamic on Linux, ++ and -optl -export-all-symbols on Windows. ++ dynamic ++ - ++ + + + +@@ -2336,13 +2673,13 @@ + + =module + Load a plugin exported by a given module +- static ++ dynamic + - + + + =module:args + Give arguments to a plugin module; module must be specified with +- static ++ dynamic + - + + +@@ -2385,6 +2722,7 @@ + Use cmd as the C compiler + dynamic + - ++ + + cmd + Use cmd as the LLVM optimiser +@@ -2397,7 +2735,6 @@ + dynamic + - + +- + + cmd + Use cmd as the splitter +@@ -2443,6 +2780,13 @@ + dynamic + - + ++ ++ cmd ++ Use cmd as the command for readelf ++ (part of Unix binutils) ++ dynamic ++ - ++ + + + +@@ -2513,12 +2857,6 @@ + - + + +- option +- pass option to the mangler +- dynamic +- - +- +- + option + pass option to the assembler + dynamic +@@ -2570,42 +2908,6 @@ + - + + +- +- +- +- (x86 only) give some registers back to the C compiler +- dynamic +- - +- +- +- +- +- +- +- +- +- External core file options +- +- +- +- +- +- +- +- Flag +- Description +- Static/Dynamic +- Reverse +- +- +- +- +- +- Generate .hcr external Core files +- dynamic +- - +- +- + + + +@@ -2665,12 +2967,6 @@ + - + + +- +- Dump output from CPR analysis +- dynamic +- - +- +- + + Dump CSE output + dynamic +@@ -2689,12 +2985,6 @@ + - + + +- +- Dump “flat” C +- dynamic +- - +- +- + + Dump foreign export stubs + dynamic +@@ -2779,12 +3069,6 @@ + - + + +- +- Dump output from each simplifier phase +- dynamic +- - +- +- + + Dump output from each simplifier iteration + dynamic +@@ -2827,6 +3111,12 @@ + - + + ++ ++ Show evaluated TH declarations in a .th.hs file ++ dynamic ++ - ++ ++ + + Dump type signatures + dynamic +@@ -2887,12 +3177,6 @@ + - + + +- +- Don't output pragma info in dumps +- static +- - +- +- + + Set the depth for printing expressions in error msgs + dynamic +@@ -3000,6 +3284,13 @@ + dynamic + - + ++ ++ ++ Report sites with rules that could have fired but didn't. ++ Takes a string argument. ++ dynamic ++ - ++ + + + +@@ -3020,7 +3311,7 @@ + + + +- ++ + When compiling with --make, compile N modules in parallel. + dynamic + - +@@ -3028,13 +3319,7 @@ + + + Don't complain about .hi file mismatches +- static +- - +- +- +- +- Turn off black holing (probably doesn't work) +- static ++ dynamic + - + + +@@ -3044,12 +3329,6 @@ + - + + +- +- Unregisterised compilation (use instead) +- static +- - +- +- + + Do not use the load/store the GHCi command history from/to ghci_history. + dynamic +diff -urd 7.8.2-original/ghc.mk original/ghc.mk +--- 7.8.2-original/ghc.mk 2014-04-08 03:26:08.000000000 +0900 ++++ original/ghc.mk 2016-04-09 21:36:11.394998369 +0900 +@@ -27,10 +27,10 @@ + + $(eval $(call clean-target,docs/users_guide,gen,$(docs/users_guide_GENERATED_DOCBOOK_SOURCES))) + +-html_docs/users_guide : docs/users_guide/users_guide/prof_scc.png ++html_docs/users_guide : docs/users_guide/users_guide/prof_scc.eps + +-docs/users_guide/users_guide/prof_scc.png : \ +- docs/users_guide/prof_scc.png \ ++docs/users_guide/users_guide/prof_scc.eps : \ ++ docs/users_guide/prof_scc.eps \ + docs/users_guide/users_guide/index.html + $(CP) $< $@ + # dep. on d/u/u/index.html is to make sure that the d/u/u dir is created first +diff -urd 7.8.2-original/ghci.xml original/ghci.xml +--- 7.8.2-original/ghci.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/ghci.xml 2016-04-09 21:36:11.394998369 +0900 +@@ -17,7 +17,7 @@ + the language extensions that GHC provides. + FFIGHCi support + Foreign Function +- InterfaceGHCi support. ++ InterfaceGHCi support + GHCi also includes an interactive debugger (see ). + + +@@ -226,7 +226,7 @@ + + We can compile D, then load the whole program, like this: + +-Prelude> :! ghc -c D.hs ++Prelude> :! ghc -c -dynamic D.hs + Prelude> :load A + Compiling B ( B.hs, interpreted ) + Compiling C ( C.hs, interpreted ) +@@ -241,6 +241,11 @@ + because the source and everything it depends on + is unchanged since the last compilation. + ++ Note the -dynamic flag to GHC: GHCi uses ++ dynamically-linked object code (if you are on a platform that ++ supports it), and so in order to use compiled code with GHCi it ++ must be compiled for dynamic linking. ++ + At any time you can use the command + :show modules + to get a list of the modules currently loaded +@@ -662,9 +667,10 @@ + an attempt to distinguish it from the new T, + which is displayed as simply T. + +- Class and type-family instance declarations are simply added to the list of available instances, with one +- exception. Since type-family instances are not permitted to overlap, but you might want to re-define one, +- a type-family instance replaces any earlier type instance with an identical left hand side. ++ Class and type-family instance declarations are simply added to the list of available instances, ++ with one exception. Since you might want to re-define one, ++ a class or type-family instance replaces any earlier instance with ++ an identical head or left hand side (respectively). + (See .) + + +@@ -2432,7 +2438,9 @@ + + Opens an editor to edit the file + file, or the most recently loaded +- module if file is omitted. The ++ module if file is omitted. ++ If there were errors during the last loading, ++ the cursor will be positioned at the line of the first error. The + editor to invoke is taken from the EDITOR + environment variable, or a default editor on your system if + EDITOR is not set. You can change the +@@ -3294,12 +3302,38 @@ + Setting options for interactive evaluation only + + +- GHCi actually maintains two sets of options: one set that +- applies when loading modules, and another set that applies for +- expressions and commands typed at the prompt. The +- :set command modifies both, but there is ++ GHCi actually maintains two sets of options: ++ ++ ++ The loading options apply when loading modules ++ ++ ++ The interactive options apply when evaluating expressions and commands typed at the GHCi prompt. ++ ++ ++The :set command modifies both, but there is + also a :seti command (for "set +- interactive") that affects only the second set. ++ interactive") that affects only the interactive options set. ++ ++ ++ ++ It is often useful to change the interactive options, ++ without having that option apply to loaded modules ++ too. For example ++ ++:seti -XMonoLocalBinds ++ ++ It would be undesirable if were to ++ apply to loaded modules too: that might cause a compilation error, but ++ more commonly it will cause extra recompilation, because GHC will think ++ that it needs to recompile the module because the flags have changed. ++ ++ ++ ++ If you are setting language options in your .ghci file, it is good practice ++ to use :seti rather than :set, ++ unless you really do want them to apply to all modules you ++ load in GHCi. + + + +@@ -3307,8 +3341,6 @@ + :set and :seti commands + respectively, with no arguments. For example, in a clean GHCi + session we might see something like this: +- +- + + Prelude> :seti + base language is: Haskell2010 +@@ -3322,38 +3354,24 @@ + -fimplicit-import-qualified + warning settings: + +- +- Note that the option +- is on, because we apply special defaulting rules to ++ ++ ++The two sets of options are initialised as follows. First, both sets of options ++are initialised as described in . ++Then the interactive options are modified as follows: ++ ++ ++ The option ++ is enabled, in order to apply special defaulting rules to + expressions typed at the prompt (see ). +- +- +- +- Furthermore, the Monomorphism Restriction is disabled by default in +- GHCi (see ). +- +- +- +- It is often useful to change the language options for expressions typed +- at the prompt only, without having that option apply to loaded modules +- too. For example +- +-:seti -XMonoLocalBinds +- +- It would be undesirable if were to +- apply to loaded modules too: that might cause a compilation error, but +- more commonly it will cause extra recompilation, because GHC will think +- that it needs to recompile the module because the flags have changed. +- ++ + +- +- It is therefore good practice if you are setting language +- options in your .ghci file, to use +- :seti rather than :set +- unless you really do want them to apply to all modules you +- load in GHCi. +- ++ ++ The Monomorphism Restriction is disabled (see ). ++ ++ ++ + + + +diff -urd 7.8.2-original/glasgow_exts.xml original/glasgow_exts.xml +--- 7.8.2-original/glasgow_exts.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/glasgow_exts.xml 2016-04-09 21:36:11.394998369 +0900 +@@ -3,7 +3,7 @@ + language, GHC + extensions, GHC + As with all known Haskell systems, GHC implements some extensions to +-the language. They can all be enabled or disabled by commandline flags ++the language. They can all be enabled or disabled by command line flags + or language pragmas. By default GHC understands the most recent Haskell + version it supports, plus a handful of extensions. + +@@ -456,10 +456,10 @@ + + + +- This can make a difference when the positive and negative range of +- a numeric data type don't match up. For example, ++ This can make a difference when the positive and negative range of ++ a numeric data type don't match up. For example, + in 8-bit arithmetic -128 is representable, but +128 is not. +- So negate (fromInteger 128) will elicit an ++ So negate (fromInteger 128) will elicit an + unexpected integer-literal-overflow message. + + +@@ -480,6 +480,26 @@ + + + ++ ++ Binary integer literals ++ ++ Haskell 2010 and Haskell 98 allows for integer literals to ++ be given in decimal, octal (prefixed by ++ 0o or 0O), or ++ hexadecimal notation (prefixed by 0x or ++ 0X). ++ ++ ++ ++ The language extension ++ adds support for expressing integer literals in binary ++ notation with the prefix 0b or ++ 0B. For instance, the binary integer ++ literal 0b11001001 will be desugared into ++ fromInteger 201 when ++ is enabled. ++ ++ + + + +@@ -857,8 +877,8 @@ + + + Pattern synonyms are enabled by the flag +--XPatternSynonyms, which is required for both +-defining them and using them. More information ++-XPatternSynonyms, which is required for defining ++them, but not for using them. More information + and examples of view patterns can be found on the Wiki + page. +@@ -967,143 +987,216 @@ + In this case, Head x + cannot be used in expressions, only patterns, since it wouldn't + specify a value for the xs on the +-right-hand side. ++right-hand side. We can give an explicit inversion of a pattern ++synonym using the following syntax: + + +- +-The semantics of a unidirectional pattern synonym declaration and +-usage are as follows: ++ ++ pattern Head x <- x:xs where ++ Head x = [x] ++ + +- ++ ++The syntax and semantics of pattern synonyms are elaborated in the ++following subsections. ++See the Wiki ++page for more details. ++ + +- Syntax: ++ Syntax and scoping of pattern synonyms + + A pattern synonym declaration can be either unidirectional or + bidirectional. The syntax for unidirectional pattern synonyms is: +- + + pattern Name args <- pat + +- + and the syntax for bidirectional pattern synonyms is: +- + + pattern Name args = pat ++ or ++ ++ pattern Name args <- pat where ++ Name args = expr + ++ Either prefix or infix syntax can be ++ used. ++ + + Pattern synonym declarations can only occur in the top level of a + module. In particular, they are not allowed as local +- definitions. Currently, they also don't work in GHCi, but that is a +- technical restriction that will be lifted in later versions. ++ definitions. ++ ++ ++ The variables in the left-hand side of the definition are bound by ++ the pattern on the right-hand side. For implicitly bidirectional ++ pattern synonyms, all the variables of the right-hand side must also ++ occur on the left-hand side; also, wildcard patterns and view ++ patterns are not allowed. For unidirectional and ++ explicitly-bidirectional pattern synonyms, there is no restriction ++ on the right-hand side pattern. ++ ++ ++ ++ Pattern synonyms cannot be defined recursively. + ++ ++ ++ Import and export of pattern synonyms ++ + + The name of the pattern synonym itself is in the same namespace as +- proper data constructors. Either prefix or infix syntax can be +- used. In export/import specifications, you have to prefix pattern ++ proper data constructors. In an export or import specification, ++ you must prefix pattern + names with the pattern keyword, e.g.: +- + + module Example (pattern Single) where + pattern Single x = [x] + +- +- +- Scoping: +- +- +- The variables in the left-hand side of the definition are bound by +- the pattern on the right-hand side. For bidirectional pattern +- synonyms, all the variables of the right-hand side must also occur +- on the left-hand side; also, wildcard patterns and view patterns are +- not allowed. For unidirectional pattern synonyms, there is no +- restriction on the right-hand side pattern. ++Without the pattern prefix, Single would ++be interpreted as a type constructor in the export list. + +- + +- Pattern synonyms cannot be defined recursively. ++You may also use the pattern keyword in an import/export ++specification to import or export an ordinary data constructor. For example: ++ ++ import Data.Maybe( pattern Just ) ++ ++would bring into scope the data constructor Just from the ++Maybe type, without also bringing the type constructor ++Maybe into scope. + ++ + +- +- +- Typing: ++ Typing of pattern synonyms + + + Given a pattern synonym definition of the form +- + + pattern P var1 var2 ... varN <- pat + +- + it is assigned a pattern type of the form +- + +- pattern CProv => P t1 t2 ... tN :: CReq => t ++ pattern P :: CProv => CReq => t1 -> t2 -> ... -> tN -> t + +- + where CProv and + CReq are type contexts, and + t1, t2, ..., + tN and t are + types. +- +- +- +-A pattern synonym of this type can be used in a pattern if the +-instatiated (monomorphic) type satisfies the constraints of +-CReq. In this case, it extends the context +-available in the right-hand side of the match with +-CProv, just like how an existentially-typed +-data constructor can extend the context. +- +- +- +-For example, in the following program: +- ++Notice the unusual form of the type, with two contexts CProv and CReq: ++ ++CReq are the constraints required to match the pattern. ++CProv are the constraints made available (provided) ++by a successful pattern match. ++ ++For example, consider + +-{-# LANGUAGE PatternSynonyms, GADTs #-} +-module ShouldCompile where +- + data T a where +- MkT :: (Show b) => a -> b -> T a ++ MkT :: (Show b) => a -> b -> T a + +-pattern ExNumPat x = MkT 42 x +- ++f1 :: (Eq a, Num a) => MkT a -> String ++f1 (MkT 42 x) = show x + +- +-the pattern type of ExNumPat is +- ++pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a ++pattern ExNumPat x = MkT 42 x + +- +-pattern (Show b) => ExNumPat b :: (Num a, Eq a) => T a ++f2 :: (Eq a, Num a) => MkT a -> String ++f2 (ExNumPat x) = show x + +- ++Here f1 does not use pattern synonyms. To match against the ++numeric pattern 42 requires the caller to ++satisfy the constraints (Num a, Eq a), ++so they appear in f1's type. The call to show generates a (Show b) ++constraint, where b is an existentially type variable bound by the pattern match ++on MkT. But the same pattern match also provides the constraint ++(Show b) (see MkT's type), and so all is well. ++ + +- and so can be used in a function definition like the following: ++Exactly the same reasoning applies to ExNumPat: ++matching against ExNumPat requires ++the constraints (Num a, Eq a), and provides ++the constraint (Show b). + ++ ++Note also the following points ++ ++ ++In the common case where CReq is empty, ++ (), it can be omitted altogether. ++ + ++ ++You may specify an explicit pattern signature, as ++we did for ExNumPat above, to specify the type of a pattern, ++just as you can for a function. As usual, the type signature can be less polymorphic ++than the inferred type. For example + +- f :: (Num t, Eq t) => T t -> String +- f (ExNumPat x) = show x ++ -- Inferred type would be 'a -> [a]' ++ pattern SinglePair :: (a, a) -> [(a, a)] ++ pattern SinglePair x = [x] + ++ + +- +- For bidirectional pattern synonyms, uses as expressions have the type +- ++ ++The GHCi :info command shows pattern types in this format. ++ ++ ++ ++For a bidirectional pattern synonym, a use of the pattern synonym as an expression has the type + + (CProv, CReq) => t1 -> t2 -> ... -> tN -> t + +- +- +- So in the previous example, ExNumPat, +- when used in an expression, has type +- ++ So in the previous example, when used in an expression, ExNumPat has type + + ExNumPat :: (Show b, Num a, Eq a) => b -> T t + ++Notice that this is a tiny bit more restrictive than the expression MkT 42 x ++which would not require (Eq a). ++ + +- ++ ++Consider these two pattern synonyms: ++ ++data S a where ++ S1 :: Bool -> S Bool + +- Matching: ++pattern P1 b = Just b -- P1 :: Bool -> Maybe Bool ++pattern P2 b = S1 b -- P2 :: (b~Bool) => Bool -> S b ++ ++f :: Maybe a -> String ++f (P1 x) = "no no no" -- Type-incorrect ++ ++g :: S a -> String ++g (P2 b) = "yes yes yes" -- Fine ++ ++Pattern P1 can only match against a value of type Maybe Bool, ++so function f is rejected because the type signature is Maybe a. ++(To see this, imagine expanding the pattern synonym.) ++ ++ ++On the other hand, function g works fine, becuase matching against P2 ++(which wraps the GADT S) provides the local equality (a~Bool). ++If you were to give an explicit pattern signature P2 :: Bool -> S Bool, then P2 ++would become less polymorphic, and would behave exactly like P1 so that g ++would then be rejected. ++ ++ ++In short, if you want GADT-like behaviour for pattern synonyms, ++then (unlike unlike concrete data constructors like S1) ++you must write its type with explicit provided equalities. ++For a concrete data construoctr like S1 you can write ++its type signature as eigher S1 :: Bool -> S Bool or ++S1 :: (b~Bool) => Bool -> S b; the two are equivalent. ++Not so for pattern synonyms: the two forms are different, in order to ++distinguish the two cases above. (See Trac #9953 for ++discussion of this choice.) ++ ++ ++ ++ ++ ++Matching of pattern synonyms + + + A pattern synonym occurrence in a pattern is evaluated by first +@@ -1119,14 +1212,12 @@ + f _ = False + + f' [x, y] | True <- x, True <- y = True +-f' _ = False ++f' _ = False + + + + Note that the strictness of f differs from that + of g defined below: +- +- + + g [True, True] = True + g _ = False +@@ -1136,9 +1227,8 @@ + *Main> g (False:undefined) + False + +- +- + ++ + + + +@@ -1883,7 +1973,8 @@ + functions (>>=), + (>>), and fail, + are in scope (not the Prelude +- versions). List comprehensions, mdo (), and parallel array ++ versions). List comprehensions, mdo ++ (), and parallel array + comprehensions, are unaffected. + + +@@ -2284,8 +2375,8 @@ + More details: + + +-Wildcards can be mixed with other patterns, including puns +-(); for example, in a pattern C {a ++Record wildcards in patterns can be mixed with other patterns, including puns ++(); for example, in a pattern (C {a + = 1, b, ..}). Additionally, record wildcards can be used + wherever record patterns occur, including in let + bindings and at the top-level. For example, the top-level binding +@@ -2297,7 +2388,7 @@ + + + +-Record wildcards can also be used in expressions, writing, for example, ++Record wildcards can also be used in an expression, when constructing a record. For example, + + let {a = 1; b = 2; c = 3; d = 4} in C {..} + +@@ -2311,7 +2402,15 @@ + + + +-The ".." expands to the missing ++Record wildcards may not be used in record updates. For example this ++is illegal: ++ ++f r = r { x = 3, .. } ++ ++ ++ ++ ++For both pattern and expression wildcards, the ".." expands to the missing + in-scope record fields. + Specifically the expansion of "C {..}" includes + f if and only if: +@@ -2328,6 +2427,8 @@ + apart from the binding of the record selector itself. + + ++These rules restrict record wildcards to the situations in which the user ++could have written the expanded version. + For example + + module M where +@@ -2342,6 +2443,18 @@ + is not in scope (apart from the binding of the + record selector c, of course). + ++ ++ ++Record wildcards cannot be used (a) in a record update construct, and (b) for data ++constructors that are not declared with record fields. For example: ++ ++f x = x { v=True, .. } -- Illegal (a) ++ ++data T = MkT Int Bool ++g = MkT { .. } -- Illegal (b) ++h (MkT { .. }) = True -- Illegal (b) ++ ++ + + + +@@ -2391,7 +2504,36 @@ + + + +- Package-qualified imports ++Import and export extensions ++ ++ ++ Hiding things the imported module doesn't export ++ ++ ++Technically in Haskell 2010 this is illegal: ++ ++module A( f ) where ++ f = True ++ ++module B where ++ import A hiding( g ) -- A does not export g ++ g = f ++ ++The import A hiding( g ) in module B ++is technically an error (Haskell Report, 5.3.1) ++because A does not export g. ++However GHC allows it, in the interests of supporting backward compatibility; for example, a newer version of ++A might export g, and you want B to work ++in either case. ++ ++ ++The warning -fwarn-dodgy-imports, which is off by default but included with -W, ++warns if you hide something that the imported module does not export. ++ ++ ++ ++ ++ Package-qualified imports + + With the flag, GHC allows + import declarations to be qualified by the package name that the +@@ -2414,10 +2556,12 @@ + added mainly so that we can build backwards-compatible versions of + packages when APIs change. It can lead to fragile dependencies in + the common case: modules occasionally move from one package to +- another, rendering any package-qualified imports broken. +- ++ another, rendering any package-qualified imports broken. ++ See also for ++ an alternative way of disambiguating between module names. ++ + +- ++ + Safe imports + + With the , +@@ -2435,15 +2579,15 @@ + safely imported. For a description of when a import is + considered safe see + +- ++ + +- ++ + Explicit namespaces in import/export + +- In an import or export list, such as ++ In an import or export list, such as + + module M( f, (++) ) where ... +- import N( f, (++) ) ++ import N( f, (++) ) + ... + + the entities f and (++) are values. +@@ -2452,12 +2596,12 @@ + case, how would you export or import it? + + +-The extension allows you to prefix the name of +-a type constructor in an import or export list with "type" to ++The extension allows you to prefix the name of ++a type constructor in an import or export list with "type" to + disambiguate this case, thus: + + module M( f, type (++) ) where ... +- import N( f, type (++) ) ++ import N( f, type (++) ) + ... + module N( f, type (++) ) where + data family a ++ b = L a | R b +@@ -2465,6 +2609,14 @@ + The extension + is implied by and (for some reason) by . + ++ ++In addition, with you can prefix the name of ++a data constructor in an import or export list with the keyword pattern, ++to allow the import or export of a data constructor without its parent type constructor ++(see ). ++ ++ ++ + + + +@@ -2688,8 +2840,11 @@ + to be written infix, very much like expressions. More specifically: + + +- A type constructor or class can be an operator, beginning with a colon; e.g. :*:. +- The lexical syntax is the same as that for data constructors. ++ A type constructor or class can be any non-reserved operator. ++ Symbols used in types are always like capitalized identifiers; they ++ are never variables. Note that this is different from the lexical ++ syntax of data constructors, which are required to begin with a ++ :. + + + Data type and type-synonym declarations can be written infix, parenthesised +@@ -2753,11 +2908,11 @@ + The language changes this behaviour: + + +-Operator symbols become type constructors rather than ++Operator symbols become type constructors rather than + type variables. + + +-Operator symbols in types can be written infix, both in definitions and uses. ++Operator symbols in types can be written infix, both in definitions and uses. + for example: + + data a + b = Plus a b +@@ -2766,8 +2921,8 @@ + + + There is now some potential ambiguity in import and export lists; for example +-if you write import M( (+) ) do you mean the +-function (+) or the ++if you write import M( (+) ) do you mean the ++function (+) or the + type constructor (+)? + The default is the former, but with (which is implied + by ) GHC allows you to specify the latter +@@ -3623,12 +3778,13 @@ + Tim Sheard. There is a longer introduction + on the wiki, + and Ralf Hinze's +-Fun with phantom types also has a number of examples. Note that papers ++Fun with phantom types also has a number of examples. Note that papers + may use different notation to that implemented in GHC. + + + The rest of this section outlines the extensions to GHC that support GADTs. The extension is enabled with +-. The flag also sets . ++. The flag also sets ++and . + + + A GADT can only be declared using GADT-style syntax (); +@@ -3809,6 +3965,13 @@ + because T is a GADT, but you can generate + the instance declaration using stand-alone deriving. + ++ ++The down-side is that, ++if the boilerplate code fails to typecheck, you will get an error message about that ++code, which you did not write. Whereas, with a deriving clause ++the side-conditions are necessarily more conservative, but any error message ++may be more comprehensible. ++ + + + +@@ -3837,9 +4000,8 @@ + + + +- +- +-Deriving clause for extra classes (<literal>Typeable</literal>, <literal>Data</literal>, etc) ++ ++Deriving instances of extra classes (<literal>Data</literal>, etc) + + + Haskell 98 allows the programmer to add "deriving( Eq, Ord )" to a data type +@@ -3851,27 +4013,6 @@ + + GHC extends this list with several more classes that may be automatically derived: + +- With , you can derive instances of the classes +-Typeable, and Data, defined in the library +-modules Data.Typeable and Data.Data respectively. +- +-Since GHC 7.8.1, Typeable is kind-polymorphic (see +-) and can be derived for any datatype and +-type class. Instances for datatypes can be derived by attaching a +-deriving Typeable clause to the datatype declaration, or by +-using standalone deriving (see ). +-Instances for type classes can only be derived using standalone deriving. +-For data families, Typeable should only be derived for the +-uninstantiated family type; each instance will then automatically have a +-Typeable instance too. +-See also . +- +- +-Also since GHC 7.8.1, handwritten (ie. not derived) instances of +-Typeable are forbidden, and will result in an error. +- +- +- + With , you can derive + instances of the classes Generic and + Generic1, defined in GHC.Generics. +@@ -3884,6 +4025,12 @@ + defined in GHC.Base. + + ++ With , you can derive instances of ++the class Data, ++defined in Data.Data. See for ++deriving Typeable. ++ ++ + With , you can derive instances of + the class Foldable, + defined in Data.Foldable. +@@ -3891,24 +4038,78 @@ + + With , you can derive instances of + the class Traversable, +-defined in Data.Traversable. ++defined in Data.Traversable. Since the Traversable ++instance dictates the instances of Functor and ++Foldable, you'll probably want to derive them too, so ++ implies ++ and . + + ++You can also use a standalone deriving declaration instead ++(see ). ++ ++ + In each case the appropriate class must be in scope before it + can be mentioned in the deriving clause. + + + +- +-Automatically deriving <literal>Typeable</literal> instances ++ ++Deriving <literal>Typeable</literal> instances ++ ++The class Typeable is very special: ++ ++ ++Typeable is kind-polymorphic (see ++). ++ ++ ++ ++GHC has a custom solver for discharging constraints that involve ++class Typeable, and handwritten instances are forbidden. ++This ensures that the programmer cannot subert the type system by ++writing bogus instances. ++ ++ ++ ++Derived instances of Typeable are ignored, ++and may be reported as an error in a later version of the compiler. ++ ++ ++ ++The rules for solving `Typeable` constraints are as follows: ++ ++A concrete type constructor applied to some types. ++ ++instance (Typeable t1, .., Typeable t_n) => ++ Typeable (T t1 .. t_n) ++ ++This rule works for any concrete type constructor, including type ++constructors with polymorhic kinds. The only restriction is that ++if the type constructor has a polymorhic kind, then it has to be applied ++to all of its kinds parameters, and these kinds need to be concrete ++(i.e., they cannot mention kind variables). ++ ++ ++ ++A type variable applied to some types. ++instance (Typeable f, Typeable t1, .., Typeable t_n) => ++ Typeable (f t1 .. t_n) ++ ++ ++ ++ ++A concrete type literal. ++instance Typeable 0 -- Type natural literals ++instance Typeable "Hello" -- Type-level symbols ++ ++ ++ ++ ++ ++ ++ + +- +-The flag triggers the generation +-of derived Typeable instances for every datatype and type +-class declaration in the module it is used. It will also generate +-Typeable instances for any promoted data constructors +-(). This flag implies +- (). + + + +@@ -4034,47 +4235,52 @@ + + A more precise specification + +-Derived instance declarations are constructed as follows. Consider the +-declaration (after expansion of any type synonyms) ++A derived instance is derived only for declarations of these forms (after expansion of any type synonyms) + + +- newtype T v1...vn = T' (t vk+1...vn) deriving (c1...cm) ++ newtype T v1..vn = MkT (t vk+1..vn) deriving (C t1..tj) ++ newtype instance T s1..sk vk+1..vn = MkT (t vk+1..vn) deriving (C t1..tj) + +- + where + + +- The ci are partial applications of +- classes of the form C t1'...tj', where the arity of C ++v1..vn are type variables, and t, ++s1..sk, t1..tj are types. ++ ++ ++ The (C t1..tj) is a partial applications of the class C, ++ where the arity of C + is exactly j+1. That is, C lacks exactly one type argument. + + +- The k is chosen so that ci (T v1...vk) is well-kinded. ++ k is chosen so that C t1..tj (T v1...vk) is well-kinded. ++(Or, in the case of a data instance, so that C t1..tj (T s1..sk) is ++well kinded.) + + + The type t is an arbitrary type. + + +- The type variables vk+1...vn do not occur in t, +- nor in the ci, and ++ The type variables vk+1...vn do not occur in the types t, ++ s1..sk, or t1..tj. + + +- None of the ci is Read, Show, ++ C is not Read, Show, + Typeable, or Data. These classes + should not "look through" the type or its constructor. You can still + derive these classes for a newtype, but it happens in the usual way, not + via this new mechanism. + + +- It is safe to coerce each of the methods of ci. That is, +- the missing last argument to each of the ci is not used +- at a nominal role in any of the ci's methods. ++ It is safe to coerce each of the methods of C. That is, ++ the missing last argument to C is not used ++ at a nominal role in any of the C's methods. + (See .) + +-Then, for each ci, the derived instance ++Then the derived instance is of form + declaration is: + +- instance ci t => ci (T v1...vk) ++ instance C t1..tj t => C t1..tj (T v1...vk) + + As an example which does not work, consider + +@@ -4116,6 +4322,25 @@ + + + ++ ++ ++Deriving any other class ++ ++ ++With you can derive any other class. The ++compiler will simply generate an empty instance. The instance context will be ++generated according to the same rules used when deriving Eq. ++This is mostly useful in classes whose minimal ++set is empty, and especially when writing ++generic functions. ++ ++In case you try to derive some class on a newtype, and ++ is also on, ++ takes precedence. ++ ++ ++ ++ + + + +@@ -4276,7 +4501,9 @@ + + + Nullary type classes +-Nullary (no parameter) type classes are enabled with . ++Nullary (no parameter) type classes are enabled with ++; historically, they were enabled with the ++(now deprecated) . + Since there are no available parameters, there can be at most one instance + of a nullary class. A nullary type class might be used to document some assumption + in a type signature (such as reliance on the Riemann hypothesis) or add some +@@ -4887,6 +5114,11 @@ + with N. + + ++ ++The flag is also used to lift some of the ++restricitions imposed on type family instances. See . ++ ++ + + + +@@ -4897,40 +5129,128 @@ + In general, as discussed in , + GHC requires that it be unambiguous which instance + declaration +-should be used to resolve a type-class constraint. This behaviour +-can be modified by two flags: ++should be used to resolve a type-class constraint. ++GHC also provides a way to to loosen ++the instance resolution, by ++allowing more than one instance to match, provided there is a most ++specific one. Moreover, it can be loosened further, by allowing more than one instance to match ++irespective of whether there is a most specific one. ++This section gives the details. ++ ++ ++To control the choice of instance, it is possible to specify the overlap behavior for individual ++instances with a pragma, written immediately after the ++instance keyword. The pragma may be one of: ++{-# OVERLAPPING #-}, ++{-# OVERLAPPABLE #-}, ++{-# OVERLAPS #-}, ++or {-# INCOHERENT #-}. ++ ++ ++The matching behaviour is also influenced by two module-level language extension flags: + -XOverlappingInstances + + and + -XIncoherentInstances +-, as this section discusses. Both these +-flags are dynamic flags, and can be set on a per-module basis, using +-an LANGUAGE pragma if desired (). ++. These flags are now deprecated (since GHC 7.10) in favour of ++the fine-grained per-instance pragmas. ++ ++ + +-The flag instructs GHC to loosen +-the instance resolution described in , by +-allowing more than one instance to match, provided there is a most +-specific one. The flag +-further loosens the resolution, by allowing more than one instance to match, +-irespective of whether there is a most specific one. ++A more precise specification is as follows. ++The willingness to be overlapped or incoherent is a property of ++the instance declaration itself, controlled as follows: ++ ++An instance is incoherent if: it has an INCOHERENT pragma; or if the instance has no pragma and it appears in a module compiled with -XIncoherentInstances. ++ ++An instance is overlappable if: it has an OVERLAPPABLE or OVERLAPS pragma; or if the instance has no pragma and it appears in a module compiled with -XOverlappingInstances; or if the instance is incoherent. ++ ++An instance is overlapping if: it has an OVERLAPPING or OVERLAPS pragma; or if the instance has no pragma and it appears in a module compiled with -XOverlappingInstances; or if the instance is incoherent. ++ ++ + + + +-For example, consider ++Now suppose that, in some client module, we are searching for an instance of the ++target constraint (C ty1 .. tyn). ++The search works like this. ++ ++ ++Find all instances I that match the target constraint; ++that is, the target constraint is a substitution instance of I. These ++instance declarations are the candidates. ++ ++ ++ ++Eliminate any candidate IX for which both of the following hold: ++ ++ ++ There is another candidate IY that is strictly more specific; ++ that is, IY is a substitution instance of IX but not vice versa. ++ ++ ++ Either IX is overlappable, or IY is ++ overlapping. (This "either/or" design, rather than a "both/and" design, ++ allow a client to deliberately override an instance from a library, without requiring a change to the library.) ++ ++ ++ ++ ++ ++ ++If exactly one non-incoherent candidate remains, select it. If all ++remaining candidates are incoherent, select an arbitary ++one. Otherwise the search fails (i.e. when more than one surviving candidate is not incoherent). ++ ++ ++ ++If the selected candidate (from the previous step) is incoherent, the search succeeds, returning that candidate. ++ ++ ++ ++If not, find all instances that unify with the target ++constraint, but do not match it. ++Such non-candidate instances might match when the target constraint is further ++instantiated. If all of them are incoherent, the search succeeds, returning the selected candidate; ++if not, the search fails. ++ ++ ++ ++Notice that these rules are not influenced by flag settings in the client module, where ++the instances are used. ++These rules make it possible for a library author to design a library that relies on ++overlapping instances without the client having to know. ++ ++ ++Errors are reported lazily (when attempting to solve a constraint), rather than eagerly ++(when the instances themselves are defined). Consider, for example + +- instance context1 => C Int b where ... -- (A) +- instance context2 => C a Bool where ... -- (B) +- instance context3 => C a [b] where ... -- (C) +- instance context4 => C Int [Int] where ... -- (D) ++ instance C Int b where .. ++ instance C a Bool where .. + +-compiled with enabled. The constraint +-C Int [Int] matches instances (A), (C) and (D), but the last ++These potentially overlap, but GHC will not complain about the instance declarations ++themselves, regardless of flag settings. If we later try to solve the constraint ++(C Int Char) then only the first instance matches, and all is well. ++Similarly with (C Bool Bool). But if we try to solve (C Int Bool), ++both instances match and an error is reported. ++ ++ ++ ++As a more substantial example of the rules in action, consider ++ ++ instance {-# OVERLAPPABLE #-} context1 => C Int b where ... -- (A) ++ instance {-# OVERLAPPABLE #-} context2 => C a Bool where ... -- (B) ++ instance {-# OVERLAPPABLE #-} context3 => C a [b] where ... -- (C) ++ instance {-# OVERLAPPING #-} context4 => C Int [Int] where ... -- (D) ++ ++Now suppose that the type inference ++engine needs to solve the constraint ++C Int [Int]. This constraint matches instances (A), (C) and (D), but the last + is more specific, and hence is chosen. + + If (D) did not exist then (A) and (C) would still be matched, but neither is +-most specific. In that case, the program would be rejected even with +-. With +- enabled, it would be accepted and (A) or ++most specific. In that case, the program would be rejected, unless ++ is enabled, in which case it would be accepted and (A) or + (C) would be chosen arbitrarily. + + +@@ -4940,7 +5260,7 @@ + substituting a:=Int. + + +-However, GHC is conservative about committing to an overlapping instance. For example: ++GHC is conservative about committing to an overlapping instance. For example: + + f :: [b] -> [b] + f x = ... +@@ -5037,60 +5357,10 @@ + would be to reject module Help + on the grounds that a later instance declaration might overlap the local one.) + +- +-The willingness to be overlapped or incoherent is a property of +-the instance declaration itself, controlled by the +-presence or otherwise of the +-and flags when that module is +-being defined. Suppose we are searching for an instance of the +-target constraint (C ty1 .. tyn). +-The search works like this. +- +- +-Find all instances I that match the target constraint; +-that is, the target constraint is a substitution instance of I. These +-instance declarations are the candidates. +- +- +- +-Find all non-candidate instances +-that unify with the target constraint. +-Such non-candidates instances might match when the target constraint is further +-instantiated. If all of them were compiled with +-, proceed; if not, the search fails. +- +- +- +-Eliminate any candidate IX for which both of the following hold: +- +- +-There is another candidate IY that is strictly more specific; +-that is, IY is a substitution instance of IX but not vice versa. +- +-Either IX or IY was compiled with +-. +- +- +- +- +- +- +-If only one candidate remains, pick it. +-Otherwise if all remaining candidates were compiled with +-, pick an arbitrary candidate. +- +- +- +-These rules make it possible for a library author to design a library that relies on +-overlapping instances without the library client having to know. +- +-The flag implies the +- flag, but not vice versa. +- + + + +-Type signatures in instance declarations ++Instance signatures: type signatures in instance declarations + In Haskell, you can't write a type signature in an instance declaration, but it + is sometimes convenient to do so, and the language extension + allows you to do so. For example: +@@ -5100,10 +5370,30 @@ + (==) :: T a -> T a -> Bool -- The signature + (==) (MkT x1 x2) (MkTy y1 y2) = x1==y1 && x2==y2 + +-The type signature in the instance declaration must be precisely the same as ++ ++Some details ++ ++ ++The type signature in the instance declaration must be more polymorphic than (or the same as) + the one in the class declaration, instantiated with the instance type. ++For example, this is fine: ++ ++ instance Eq a => Eq (T a) where ++ (==) :: forall b. b -> b -> Bool ++ (==) x y = True ++ ++Here the signature in the instance declaration is more polymorphic than that ++required by the instantiated class method. + +- ++ ++ ++ ++The code for the method in the instance declaration is typechecked against the type signature ++supplied in the instance declaration, as you would expect. So if the instance signature ++is more polymorphic than required, the code must be too. ++ ++ ++ + One stylistic reason for wanting to write a type signature is simple documentation. Another + is that you may want to bring scoped type variables into scope. For example: + +@@ -5121,7 +5411,8 @@ + (), + the forall b scopes over the definition of foo, + and in particular over the type signature for xs. +- ++ ++ + + + +@@ -5160,21 +5451,30 @@ + from module GHC.Exts. + + +-Haskell's defaulting mechanism is extended to cover string literals, when is specified. ++Haskell's defaulting mechanism (Haskell Report, Section 4.3.4) ++is extended to cover string literals, when is specified. + Specifically: + + +-Each type in a default declaration must be an ++Each type in a default declaration must be an + instance of Num or of IsString. + + + +-The standard defaulting rule (Haskell Report, Section 4.3.4) ++If no default declaration is given, then it is just as if the module ++contained the declaration default( Integer, Double, String). ++ ++ ++ ++The standard defaulting rule + is extended thus: defaulting applies when all the unresolved constraints involve standard classes + or IsString; and at least one is a numeric class + or IsString. + + ++So, for example, the expression length "foo" will give rise ++to an ambiguous use of IsString a0 which, because of the above ++rules, will default to String. + + + A small example: +@@ -5276,7 +5576,7 @@ + fromListN _ = fromList + + +-The FromList class and its methods are intended to be ++The IsList class and its methods are intended to be + used in conjunction with the extension. + + The type function +@@ -5308,32 +5608,32 @@ + useful for completely new data types. + Here are several example instances: + +-instance FromList [a] where ++instance IsList [a] where + type Item [a] = a + fromList = id + toList = id + +-instance (Ord a) => FromList (Set a) where ++instance (Ord a) => IsList (Set a) where + type Item (Set a) = a + fromList = Set.fromList + toList = Set.toList + +-instance (Ord k) => FromList (Map k v) where ++instance (Ord k) => IsList (Map k v) where + type Item (Map k v) = (k,v) + fromList = Map.fromList + toList = Map.toList + +-instance FromList (IntMap v) where ++instance IsList (IntMap v) where + type Item (IntMap v) = (Int,v) + fromList = IntMap.fromList + toList = IntMap.toList + +-instance FromList Text where ++instance IsList Text where + type Item Text = Char + fromList = Text.pack + toList = Text.unpack + +-instance FromList (Vector a) where ++instance IsList (Vector a) where + type Item (Vector a) = a + fromList = Vector.fromList + fromListN = Vector.fromListN +@@ -5901,28 +6201,39 @@ + data GMap (Either a b) v = GMapEither (GMap a v) (GMap b v) + ... + +-instance (Eq (Elem [e])) => Collects ([e]) where ++instance Eq (Elem [e]) => Collects [e] where + type Elem [e] = e + ... + +- The most important point about associated family instances is that the +- type indexes corresponding to class parameters must be identical to +- the type given in the instance head; here this is the first argument +- of GMap, namely Either a b, +- which coincides with the only class parameter. +- +- +- Instances for an associated family can only appear as part of +- instance declarations of the class in which the family was declared - +- just as with the equations of the methods of a class. Also in +- correspondence to how methods are handled, declarations of associated +- types can be omitted in class instances. If an associated family +- instance is omitted, the corresponding instance type is not inhabited; ++Note the following points: ++ ++ ++ The type indexes corresponding to class parameters must have precisely the same shape ++ the type given in the instance head. To have the same "shape" means that ++ the two types are identical modulo renaming of type variables. For example: ++ ++instance Eq (Elem [e]) => Collects [e] where ++ -- Choose one of the following alternatives: ++ type Elem [e] = e -- OK ++ type Elem [x] = x -- OK ++ type Elem x = x -- BAD; shape of 'x' is different to '[e]' ++ type Elem [Maybe x] = x -- BAD: shape of '[Maybe x]' is different to '[e]' ++ ++ ++ ++ An instances for an associated family can only appear as part of ++ an instance declarations of the class in which the family was declared, ++ just as with the equations of the methods of a class. ++ ++ ++ The instance for an associated type can be omitted in class instances. In that case, ++ unless there is a default instance (see ), ++ the corresponding instance type is not inhabited; + i.e., only diverging expressions, such + as undefined, can assume the type. +- +- +- Although it is unusual, there can be multiple ++ ++ ++ Although it is unusual, there (currently) can be multiple + instances for an associated family in a single instance declaration. + For example, this is legitimate: + +@@ -5936,8 +6247,10 @@ + Since you cannot give any subsequent instances for + (GMap Flob ...), this facility is most useful when + the free indexed parameter is of a kind with a finite number of alternatives +- (unlike *). +- ++ (unlike *). WARNING: this facility may be withdrawn in the future. ++ ++ ++ + + + +@@ -5955,22 +6268,50 @@ + instance IsBoolMap [(Int, Bool)] where + lookupKey = lookup + +-The instance keyword is optional. +- ++In an instance declaration for the class, if no explicit ++type instance declaration is given for the associated type, the default declaration ++is used instead, just as with default class methods. ++ + +-There can also be multiple defaults for a single type, as long as they do not +-overlap: ++Note the following points: ++ ++ ++ The instance keyword is optional. ++ ++ ++ There can be at most one default declaration for an associated type synonym. ++ ++ ++ A default declaration is not permitted for an associated ++ data type. ++ ++ ++ The default declaration must mention only type variables on the left hand side, ++ and the right hand side must mention only type varaibels bound on the left hand side. ++ However, unlike the associated type family declaration itself, ++ the type variables of the default instance are independent of those of the parent class. ++ ++ ++Here are some examples: + +-class C a where +- type F a b +- type F a Int = Bool +- type F a Bool = Int ++ class C a where ++ type F1 a :: * ++ type instance F1 a = [a] -- OK ++ type instance F1 a = a->a -- BAD; only one default instance is allowed ++ ++ type F2 b a -- OK; note the family has more type ++ -- variables than the class ++ type instance F2 c d = c->d -- OK; you don't have to use 'a' in the type instance ++ ++ type F3 a ++ type F3 [b] = b -- BAD; only type variables allowed on the LHS ++ ++ type F4 a ++ type F4 b = a -- BAD; 'a' is not in scope in the RHS + ++ + +-A default declaration is not permitted for an associated +-data type. +- +- ++ + + + Scoping of class parameters +@@ -6312,11 +6653,11 @@ + + The recursive use of T forced the second argument to have kind *. + However, just as in type inference, you can achieve polymorphic recursion by giving a +-complete kind signature for T. The way to give +-a complete kind signature for a data type is to use a GADT-style declaration with an +-explicit kind signature thus: ++complete kind signature for T. A complete ++kind signature is present when all argument kinds and the result kind are known, without ++any need for inference. For example: + +-data T :: (k -> *) -> k -> * where ++data T (m :: k -> *) :: k -> * where + MkT :: m a -> T Maybe (m a) -> T m a + + The complete user-supplied kind signature specifies the polymorphic kind for T, +@@ -6328,26 +6669,41 @@ + What exactly is considered to be a "complete user-supplied kind signature" for a type constructor? + These are the forms: + +- +-A GADT-style data type declaration, with an explicit "::" in the header. +-For example: ++For a datatype, every type variable must be annotated with a kind. In a ++GADT-style declaration, there may also be a kind signature (with a top-level ++:: in the header), but the presence or absence of this annotation ++does not affect whether or not the declaration has a complete signature. + + data T1 :: (k -> *) -> k -> * where ... -- Yes T1 :: forall k. (k->*) -> k -> * + data T2 (a :: k -> *) :: k -> * where ... -- Yes T2 :: forall k. (k->*) -> k -> * + data T3 (a :: k -> *) (b :: k) :: * where ... -- Yes T3 :: forall k. (k->*) -> k -> * +-data T4 a (b :: k) :: * where ... -- YES T4 :: forall k. * -> k -> * ++data T4 (a :: k -> *) (b :: k) where ... -- Yes T4 :: forall k. (k->*) -> k -> * + +-data T5 a b where ... -- NO kind is inferred +-data T4 (a :: k -> *) (b :: k) where ... -- NO kind is inferred +- +-It makes no difference where you put the "::" but it must be there. +-You cannot give a complete kind signature using a Haskell-98-style data type declaration; +-you must use GADT syntax. ++data T5 a (b :: k) :: * where ... -- NO kind is inferred ++data T6 a b where ... -- NO kind is inferred ++ ++ ++ ++ ++For a class, every type variable must be annotated with a kind. + + + ++For a type synonym, every type variable and the result type must all be annotated ++with kinds. ++ ++type S1 (a :: k) = (a :: k) -- Yes S1 :: forall k. k -> k ++type S2 (a :: k) = a -- No kind is inferred ++type S3 (a :: k) = Proxy a -- No kind is inferred ++ ++Note that in S2 and S3, the kind of the ++right-hand side is rather apparent, but it is still not considered to have a complete ++signature -- no inference can be done before detecting the signature. ++ ++ + An open type or data family declaration always has a +-complete user-specified kind signature; no "::" is required: ++complete user-specified kind signature; un-annotated type variables default to ++kind *. + + data family D1 a -- D1 :: * -> * + data family D2 (a :: k) -- D2 :: forall k. k -> * +@@ -6362,10 +6718,12 @@ + in the associated type declaration. The variable b, however, + gets defaulted to *. + ++ ++ ++A closed type familey has a complete signature when all of its type variables ++are annotated and a return kind (with a top-level ::) is supplied. ++ + +-In a complete user-specified kind signature, any un-decorated type variable to the +-left of the "::" is considered to have kind "*". +-If you want kind polymorphism, specify a kind variable. + + + +@@ -6375,31 +6733,33 @@ + Although all open type families are considered to have a complete + user-specified kind signature, we can relax this condition for closed type + families, where we have equations on which to perform kind inference. GHC will +-infer a kind for any type variable in a closed type family when that kind is +-never used in pattern-matching. If you want a kind variable to be used in +-pattern-matching, you must declare it explicitly. +- ++infer kinds for the arguments and result types of a closed type family. + +- +-Here are some examples (assuming -XDataKinds is enabled): +- +-type family Not a where -- Not :: Bool -> Bool +- Not False = True +- Not True = False ++GHC supports kind-indexed type families, where the ++family matches both on the kind and type. GHC will not infer ++this behaviour without a complete user-supplied kind signature, as doing so would ++sometimes infer non-principal types. + +-type family F a where -- ERROR: requires pattern-matching on a kind variable +- F Int = Bool +- F Maybe = Char ++For example: ++ ++type family F1 a where ++ F1 True = False ++ F1 False = True ++ F1 x = x ++-- F1 fails to compile: kind-indexing is not inferred + +-type family G (a :: k) where -- G :: k -> * +- G Int = Bool +- G Maybe = Char ++type family F2 (a :: k) where ++ F2 True = False ++ F2 False = True ++ F2 x = x ++-- F2 fails to compile: no complete signature + +-type family SafeHead where -- SafeHead :: [k] -> Maybe k +- SafeHead '[] = Nothing -- note that k is not required for pattern-matching +- SafeHead (h ': t) = Just h +- +- ++type family F3 (a :: k) :: k where ++ F3 True = False ++ F3 False = True ++ F3 x = x ++-- OK ++ + + + +@@ -6569,9 +6929,9 @@ + + + + +@@ -6871,7 +7246,7 @@ + type (Show a, Ord a) is of kind Constraint. + + +- Anything whose form is not yet know, but the user has declared to have kind Constraint ++ Anything whose form is not yet known, but the user has declared to have kind Constraint + (for which they need to import it from GHC.Exts). So for example + type Foo (f :: * -> Constraint) = forall b. f b => b -> b is allowed, as well as + examples involving type families: +@@ -6974,13 +7349,13 @@ + + + Each user-written type signature is subjected to an +-ambiguity check. ++ambiguity check. + The ambiguity check rejects functions that can never be called; for example: + + f :: C a => Int + + The idea is there can be no legal calls to f because every call will +-give rise to an ambiguous constraint. ++give rise to an ambiguous constraint. + Indeed, the only purpose of the + ambiguity check is to report functions that cannot possibly be called. + We could soundly omit the +@@ -6992,7 +7367,7 @@ + Ambiguity can be subtle. Consider this example which uses functional dependencies: + + class D a b | a -> b where .. +- h :: D Int b => Int ++ h :: D Int b => Int + + The Int may well fix b at the call site, so that signature should + not be rejected. Moreover, the dependencies might be hidden. Consider +@@ -7007,12 +7382,12 @@ + ...(h [True])... + + That gives rise to a (X [Bool] beta) constraint, and using the +-instance means we need (D Bool beta) and that ++instance means we need (D Bool beta) and that + fixes beta via D's + fundep! + + +-Behind all these special cases there is a simple guiding principle. ++Behind all these special cases there is a simple guiding principle. + Consider + + f :: type +@@ -7022,7 +7397,7 @@ + g = f + + You would think that the definition of g would surely typecheck! +-After all f has exactly the same type, and g=f. ++After all f has exactly the same type, and g=f. + But in fact f's type + is instantiated and the instantiated constraints are solved against + the constraints bound by g's signature. So, in the case an ambiguous type, solving will fail. +@@ -7076,7 +7451,7 @@ + on type signatures. For type type + forall tv1..tvn (c1, ...,cn) => type + GHC used to require (a) that each universally quantified type variable +-tvi must be "reachable" from type, ++tvi must be "reachable" from type, + and (b) that every constraint ci mentions at least one of the + universally quantified type variables tvi. + These ad-hoc restrictions are completely subsumed by the new ambiguity check. +@@ -7308,6 +7683,57 @@ + 14. + + ++ ++ ++Special implicit parameters ++ ++GHC treats implicit parameters of type GHC.Stack.CallStack ++specially, by resolving them to the current location in the program. Consider: ++ ++ f :: String ++ f = show (?loc :: CallStack) ++ ++GHC will automatically resolve ?loc to its source ++location. If another implicit parameter with type CallStack is ++in scope, GHC will append the two locations, creating an explicit call-stack. For example: ++ ++ f :: (?stk :: CallStack) => String ++ f = show (?stk :: CallStack) ++ ++will produce the location of ?stk, followed by ++f's call-site. Note that the name of the implicit parameter does not ++matter (we used ?loc above), GHC will solve any implicit parameter ++with the right type. The name does, however, matter when pushing new locations onto ++existing stacks. Consider: ++ ++ f :: (?stk :: CallStack) => String ++ f = show (?loc :: CallStack) ++ ++When we call f, the stack will include the use of ?loc, ++but not the call to f; in this case the names must match. ++ ++ ++CallStack is kept abstract, but ++GHC provides a function ++ ++ getCallStack :: CallStack -> [(String, SrcLoc)] ++ ++to access the individual call-sites in the stack. The String ++is the name of the function that was called, and the SrcLoc ++provides the package, module, and file name, as well as the line and column ++numbers. The stack will never be empty, as the first call-site ++will be the location at which the implicit parameter was used. GHC will also ++never infer ?loc :: CallStack as a type constraint, which ++means that functions must explicitly ask to be told about their call-sites. ++ ++ ++A potential "gotcha" when using implicit CallStacks is that ++the :type command in GHCi will not report the ++?loc :: CallStack constraint, as the typechecker will ++immediately solve it. Use :info instead to print the ++unsolved type. ++ ++ + + + +@@ -7457,7 +7883,7 @@ + bind :: forall a b. m a -> (a -> m b) -> m b + } + +-newtype Swizzle = MkSwizzle (Ord a => [a] -> [a]) ++newtype Swizzle = MkSwizzle (forall a. Ord a => [a] -> [a]) + + + +@@ -7473,22 +7899,22 @@ + MkMonad :: forall m. (forall a. a -> m a) + -> (forall a b. m a -> (a -> m b) -> m b) + -> MonadT m +-MkSwizzle :: (Ord a => [a] -> [a]) -> Swizzle ++MkSwizzle :: (forall a. Ord a => [a] -> [a]) -> Swizzle + + + + + +-Notice that you don't need to use a forall if there's an +-explicit context. For example in the first argument of the +-constructor MkSwizzle, an implicit "forall a." is +-prefixed to the argument type. The implicit forall +-quantifies all type variables that are not already in scope, and are +-mentioned in the type quantified over. (Arguably, it would be better +-to require explicit quantification on constructor arguments +-where that is what is wanted. +-See Trac #4426.) ++In earlier versions of GHC, it was possible to omit the forall ++in the type of the constructor if there was an explicit context. For example: + ++ ++newtype Swizzle' = MkSwizzle' (Ord a => [a] -> [a]) ++ ++ ++As of GHC 7.10, this is deprecated. The -fwarn-context-quantification ++flag detects this situation and issues a warning. In GHC 7.12, declarations ++such as MkSwizzle' will cause an out-of-scope error. + + + +@@ -7998,7 +8424,7 @@ + of the Haskell Report) + can be completely switched off by + . Since GHC 7.8.1, the monomorphism +-restriction is switched off by default in GHCi. ++restriction is switched off by default in GHCi's interactive options (see ). + + + +@@ -8071,12 +8497,30 @@ + + An ML-style language usually generalises the type of any let-bound or where-bound variable, + so that it is as polymorphic as possible. +-With the flag GHC implements a slightly more conservative policy: +-it generalises only "closed" bindings. +-A binding is considered "closed" if either ++With the flag GHC implements a slightly more conservative policy, ++using the following rules: + +-It is one of the top-level bindings of a module, or +-Its free variables are all themselves closed ++ ++ A variable is closed if and only if ++ ++ the variable is let-bound ++ one of the following holds: ++ ++ the variable has an explicit type signature that has no free type variables, or ++ its binding group is fully generalised (see next bullet) ++ ++ ++ ++ ++ ++ ++ A binding group is fully generalised if and only if ++ ++ each of its free variables is either imported or closed, and ++ the binding is not affected by the monomorphism restriction ++ (Haskell Report, Section 4.5.5) ++ ++ + + For example, consider + +@@ -8085,15 +8529,18 @@ + k z = z+x + in h x + k x + +-Here f and g are closed because they are bound at top level. +-Also h is closed because its only free variable f is closed. +-But k is not closed because it mentions x which is locally bound. +-Another way to think of it is this: all closed bindings could be defined at top level. +-(In the example, we could move h to top level.) +- +-All of this applies only to bindings that lack an explicit type signature, so that GHC has to +-infer its type. If you supply a type signature, then that fixes type of the binding, end of story. +- ++Here f is generalised because it has no free variables; and its binding group ++is unaffected by the monomorphism restriction; and hence f is closed. ++The same reasoning applies to g, except that it has one closed free variable, namely f. ++Similarly h is closed, even though it is not bound at top level, ++because its only free variable f is closed. ++But k is not closed, because it mentions x which is not closed (because it is not let-bound). ++ ++ ++Notice that a top-level binding that is affected by the monomorphism restriction is not closed, and hence may ++in turn prevent generalisation of bindings that mention it. ++ ++ + The rationale for this more conservative strategy is given in + the papers "Let should not be generalised" and "Modular type inference with local assumptions", and + a related blog post. +@@ -8110,31 +8557,37 @@ + + Typed Holes + +-Typed hole support is enabled with the option +-, which is enabled by default. +- + +-This option allows special placeholders, written with a leading underscore (e.g. "_", +-"_foo", "_bar"), to be used as an expression. +-During compilation these holes will generate an error message describing what type is expected there, +-information about the origin of any free type variables, and a list of local bindings +-that might help fill the hole with actual code. ++Typed holes are a feature of GHC that allows special placeholders written with ++a leading underscore (e.g., "_", "_foo", ++"_bar"), to be used as expressions. During compilation these ++holes will generate an error message that describes which type is expected at ++the hole's location, information about the origin of any free type variables, ++and a list of local bindings that might help fill the hole with actual code. ++Typed holes are always enabled in GHC. + + + +-The goal of the typed holes warning is not to change the type system, but to help with writing Haskell +-code. Typed holes can be used to obtain extra information from the type checker, which might otherwise be hard +-to get. +-Normally, using GHCi, users can inspect the (inferred) type signatures of all top-level bindings. +-However, this method is less convenient with terms which are not defined on top-level or +-inside complex expressions. Holes allow to check the type of the term you're about to write. ++The goal of typed holes is to help with writing Haskell code rather than to ++change the type system. Typed holes can be used to obtain extra information ++from the type checker, which might otherwise be hard to get. Normally, using ++GHCi, users can inspect the (inferred) type signatures of all top-level ++bindings. However, this method is less convenient with terms that are not ++defined on top-level or inside complex expressions. Holes allow the user to ++check the type of the term they are about to write. + + + +-Holes work together well with deferring type errors to runtime: +-with -fdefer-type-errors, the error from a hole is also deferred, effctively making the hole +-typecheck just like undefined, but with the added benefit that it will show its warning message +-if it gets evaluated. This way, other parts of the code can still be executed and tested. ++To run and test a piece of code containing holes, use the ++-fdefer-typed-holes flag. This flag defers errors ++produced by typed holes and converts them into warnings. The result is that ++typed hole errors are converted into warnings (controlled by ++-fwarn-typed-holes). The result is that a hole will behave ++like undefined, but with the added benefits that it shows a ++warning at compile time and will show another warning message if it gets ++evaluated. This behaviour follows that of the ++-fdefer-type-errors option, which implies ++-fdefer-typed-holes. See . + + + +@@ -8211,6 +8664,293 @@ + + + ++ ++ ++ ++Partial Type Signatures ++ ++ ++A partial type signature is a type signature containing special placeholders ++written with a leading underscore (e.g., "_", ++"_foo", "_bar") called ++wildcards. Partial type signatures are to type signatures ++what are to expressions. During compilation these ++wildcards or holes will generate an error message that describes which type ++was inferred at the hole's location, and information about the origin of any ++free type variables. GHC reports such error messages by default. ++ ++ ++Unlike , which make the program incomplete and ++will generate errors when they are evaluated, this needn't be the case for ++holes in type signatures. The type checker is capable (in most cases) of ++type-checking a binding with or without a type signature. A partial type ++signature bridges the gap between the two extremes, the programmer can choose ++which parts of a type to annotate and which to leave over to the type-checker ++to infer. ++ ++ ++ ++By default, the type-checker will report an error message for each hole in a ++partial type signature, informing the programmer of the inferred type. When ++the flag is enabled, the type-checker ++will accept the inferred type for each hole, generating warnings instead of ++errors. Additionally, these warnings can be silenced with the ++ flag. ++ ++ ++ ++Syntax ++ ++ ++A (partial) type signature has the following form: forall a b .. . ++(C1, C2, ..) => tau. It consists of three parts: ++ ++ ++ ++ The type variables: a b .. ++ The constraints: (C1, C2, ..) ++ The (mono)type: tau ++ ++ ++ ++We distinguish three kinds of wildcards. ++ ++ ++ ++Type Wildcards ++ ++Wildcards occurring within the monotype (tau) part of the type signature are ++type wildcards ("type" is often omitted as this is the ++default kind of wildcard). Type wildcards can be instantiated to any monotype ++like Bool or Maybe [Bool], including ++functions and higher-kinded types like (Int -> Bool) or ++Maybe. ++ ++ ++not' :: Bool -> _ ++not' x = not x ++-- Inferred: Bool -> Bool ++ ++maybools :: _ ++maybools = Just [True] ++-- Inferred: Maybe [Bool] ++ ++just1 :: _ Int ++just1 = Just 1 ++-- Inferred: Maybe Int ++ ++filterInt :: _ -> _ -> [Int] ++filterInt = filter -- has type forall a. (a -> Bool) -> [a] -> [a] ++-- Inferred: (Int -> Bool) -> [Int] -> [Int] ++ ++ ++ ++For instance, the first wildcard in the type signature not' ++would produce the following error message: ++ ++ ++Test.hs:4:17: ++ Found hole ‘_’ with type: Bool ++ To use the inferred type, enable PartialTypeSignatures ++ In the type signature for ‘not'’: Bool -> _ ++ ++ ++ ++When a wildcard is not instantiated to a monotype, it will be generalised ++over, i.e. replaced by a fresh type variable (of which the name will often ++start with w_), e.g. ++ ++ ++foo :: _ -> _ ++foo x = x ++-- Inferred: forall w_. w_ -> w_ ++ ++filter' :: _ ++filter' = filter -- has type forall a. (a -> Bool) -> [a] -> [a] ++-- Inferred: (a -> Bool) -> [a] -> [a] ++ ++ ++ ++ ++Named Wildcards ++ ++Type wildcards can also be named by giving the underscore an identifier as ++suffix, i.e. _a. These are called named ++wildcards. All occurrences of the same named wildcard within one ++type signature will unify to the same type. For example: ++ ++ ++f :: _x -> _x ++f ('c', y) = ('d', error "Urk") ++-- Inferred: forall t. (Char, t) -> (Char, t) ++ ++ ++ ++The named wildcard forces the argument and result types to be the same. ++Lacking a signature, GHC would have inferred forall a b. (Char, a) -> ++(Char, b). A named wildcard can be mentioned in constraints, ++provided it also occurs in the monotype part of the type signature to make ++sure that it unifies with something: ++ ++ ++ ++somethingShowable :: Show _x => _x -> _ ++somethingShowable x = show x ++-- Inferred type: Show w_x => w_x -> String ++ ++somethingShowable' :: Show _x => _x -> _ ++somethingShowable' x = show (not x) ++-- Inferred type: Bool -> String ++ ++ ++ ++Besides an extra-constraints wildcard (see ), only named wildcards can occur in the ++constraints, e.g. the _x in Show _x. ++ ++ ++ ++Named wildcards should not be confused with type ++variables. Even though syntactically similar, named wildcards can ++unify with monotypes as well as be generalised over (and behave as type ++variables). ++ ++ ++In the first example above, _x is generalised over (and is ++effectively replaced by a fresh type variable w_x). In the ++second example, _x is unified with the ++Bool type, and as Bool implements the ++Show type class, the constraint Show ++Bool can be simplified away. ++ ++ ++ ++By default, GHC (as the Haskell 2010 standard prescribes) parses identifiers ++starting with an underscore in a type as type variables. To treat them as ++named wildcards, the flag should be enabled. ++The example below demonstrated the effect. ++ ++ ++ ++foo :: _a -> _a ++foo _ = False ++ ++ ++ ++Compiling this program without enabling ++produces the following error message complaining about the type variable ++_a no matching the actual type Bool. ++ ++ ++ ++Test.hs:5:9: ++ Couldn't match expected type ‘_a’ with actual type ‘Bool’ ++ ‘_a’ is a rigid type variable bound by ++ the type signature for foo :: _a -> _a at Test.hs:4:8 ++ Relevant bindings include foo :: _a -> _a (bound at Test.hs:4:1) ++ In the expression: False ++ In an equation for ‘foo’: foo _ = False ++ ++ ++ ++Compiling this program with enabled produces ++the following error message reporting the inferred type of the named wildcard ++_a. ++ ++ ++ ++Test.hs:4:8: Warning: ++ Found hole ‘_a’ with type: Bool ++ In the type signature for ‘foo’: _a -> _a ++ ++ ++ ++ ++Extra-Constraints Wildcard ++ ++ ++The third kind of wildcard is the extra-constraints ++wildcard. The presence of an extra-constraints wildcard indicates ++that an arbitrary number of extra constraints may be inferred during type ++checking and will be added to the type signature. In the example below, the ++extra-constraints wildcard is used to infer three extra constraints. ++ ++ ++ ++arbitCs :: _ => a -> String ++arbitCs x = show (succ x) ++ show (x == x) ++-- Inferred: ++-- forall a. (Enum a, Eq a, Show a) => a -> String ++-- Error: ++Test.hs:5:12: ++ Found hole ‘_’ with inferred constraints: (Enum a, Eq a, Show a) ++ To use the inferred type, enable PartialTypeSignatures ++ In the type signature for ‘arbitCs’: _ => a -> String ++ ++ ++ ++An extra-constraints wildcard shouldn't prevent the programmer from already ++listing the constraints he knows or wants to annotate, e.g. ++ ++ ++ ++-- Also a correct partial type signature: ++arbitCs' :: (Enum a, _) => a -> String ++arbitCs' x = arbitCs x ++-- Inferred: ++-- forall a. (Enum a, Show a, Eq a) => a -> String ++-- Error: ++Test.hs:9:22: ++ Found hole ‘_’ with inferred constraints: (Eq a, Show a) ++ To use the inferred type, enable PartialTypeSignatures ++ In the type signature for ‘arbitCs'’: (Enum a, _) => a -> String ++ ++ ++ ++An extra-constraints wildcard can also lead to zero extra constraints to be ++inferred, e.g. ++ ++ ++ ++noCs :: _ => String ++noCs = "noCs" ++-- Inferred: String ++-- Error: ++Test.hs:13:9: ++ Found hole ‘_’ with inferred constraints: () ++ To use the inferred type, enable PartialTypeSignatures ++ In the type signature for ‘noCs’: _ => String ++ ++ ++ ++As a single extra-constraints wildcard is enough to infer any number of ++constraints, only one is allowed in a type signature and it should come last ++in the list of constraints. ++ ++ ++ ++Extra-constraints wildcards cannot be named. ++ ++ ++ ++ ++ ++ ++Where can they occur? ++ ++ ++Partial type signatures are allowed for bindings, pattern and expression signatures. ++In all other contexts, e.g. type class or type family declarations, they are disallowed. ++In the following example a wildcard is used in each of the three possible contexts. ++ ++ ++{-# LANGUAGE ScopedTypeVariables #-} ++foo :: _ ++foo (x :: _) = (x :: _) ++-- Inferred: forall w_. w_ -> w_ ++ ++ ++ + + + +@@ -8245,6 +8985,15 @@ + warnings, but will not prevent compilation. + + ++ This flag implies the -fdefer-typed-holes flag, ++ which enables this behaviour for typed holes ++ . Should you so wish, it is possible to enable ++ -fdefer-type-errors without enabling ++ -fdefer-typed-holes, by explicitly specifying ++ -fno-defer-typed-holes on the commandline after the ++ -fdefer-type-errors flag. ++ ++ + At runtime, whenever a term containing a type error would need to be + evaluated, the error is converted into a runtime exception. + Note that type errors are deferred as much as possible during runtime, but +@@ -8364,11 +9113,13 @@ + have type Q Pat + a type; the spliced expression must + have type Q Type +- a list of declarations; the spliced expression ++ a list of declarations at top level; the spliced expression + must have type Q [Dec] + + Inside a splice you can only call functions defined in imported modules, +- not functions defined elsewhere in the same module. ++ not functions defined elsewhere in the same module. Note that ++ declaration splices are not allowed anywhere except at top level ++ (outside any other declarations). + + + A expression quotation is written in Oxford brackets, thus: +@@ -8469,28 +9220,57 @@ + + This abbreviation makes top-level declaration slices quieter and less intimidating. + +- ++ + + +- Binders are lexically scoped. For example, consider the +- following code, where a value g of type +- Bool -> Q Pat is in scope, having been +- imported from another module ++ Outermost pattern splices may bind variables. By "outermost" here, we refer to ++ a pattern splice that occurs outside of any quotation brackets. For example, ++ + +-y :: Int +-y = 7 ++mkPat :: Bool -> Q Pat ++mkPat True = [p| (x, y) |] ++mkPat False = [p| (y, x) |] + +-f :: Int -> Int -> Int +-f n = \ $(g True) -> y+n ++-- in another module: ++foo :: (Char, String) -> String ++foo $(mkPat True) = x : y ++ ++bar :: (String, Char) -> String ++bar $(mkPat False) = x : y + +- The y in the right-hand side of +- f refers to the top-level y = +- 7, even if the pattern splice $(g +- n) also generates a binder y. + ++ ++ + ++ + +- Note that a pattern quasiquoter may ++ Nested pattern splices do not bind variables. ++ By "nested" here, we refer to a pattern splice occurring within a ++ quotation bracket. Continuing the example from the last bullet: ++ ++ ++baz :: Bool -> Q Exp ++baz b = [| quux $(mkPat b) = x + y |] ++ ++ ++ would fail with x and y ++ being out of scope. ++ ++ ++ ++ The difference in treatment of outermost and nested pattern splices is ++ because outermost splices are run at compile time. GHC can then use ++ the result of running the splice when analyzing the expressions within ++ the pattern's scope. Nested splices, on the other hand, are not ++ run at compile time; they are run when the bracket is spliced in, sometime later. ++ Since nested pattern splices may refer to local variables, there is no way for GHC ++ to know, at splice compile time, what variables are bound, so it binds none. ++ ++ ++ ++ ++ ++ A pattern quasiquoter may + generate binders that scope over the right-hand side of a + definition because these binders are in scope lexically. For + example, given a quasiquoter haskell that +@@ -8509,21 +9289,29 @@ + + + +- +- The type environment seen by reify includes +- all the top-level declaration up to the end of the immediately +- preceding declaration group, but no more. ++ ++ Top-level declaration splices break up a source file into ++ delcaration groups. A ++ declaration group is the group of ++ declarations created by a top-level declaration splice, plus ++ those following it, down to but not including the next ++ top-level declaration splice. The first declaration group in a ++ module includes all top-level definitions down to but not ++ including the first top-level declaration splice. + + + +- A declaration group is the group of +- declarations created by a top-level declaration splice, plus +- those following it, down to but not including the next top-level +- declaration splice. The first declaration group in a module +- includes all top-level definitions down to but not including the +- first top-level declaration splice. ++ Each declaration group is mutually recursive only within ++ the group. Declaration groups can refer to definitions within ++ previous groups, but not later ones. + + ++ ++ Accordingly, the type environment seen by ++ reify includes all the top-level ++ declarations up to the end of the immediately preceding ++ declaration group, but no more. ++ + + + Concretely, consider the following code +@@ -8541,6 +9329,11 @@ + + + ++ The body of h would be unable to refer ++ to the function w. ++ ++ ++ + A reify inside the splice $(th1 + ..) would see the definition of + f. +@@ -8610,9 +9403,6 @@ + + + +- The flag -ddump-splices shows the expansion of all top-level splices as they happen. +- +- + If you are building GHC from source, you need at least a stage-2 bootstrap compiler to + run Template Haskell. A stage-1 compiler will reject the TH constructs. Reason: TH + compiles and runs a program, and then looks at the result. So it's important that +@@ -8627,6 +9417,45 @@ + + + ++ Viewing Template Haskell generated code ++ ++ The flag -ddump-splices shows the expansion of all top-level declaration splices, both typed and untyped, as they happen. ++ As with all dump flags, the default is for this output to be sent to stdout. ++ For a non-trivial program, you may be interested in combining this with the -ddump-to-file flag (see . ++ For each file using Template Haskell, this will show the output in a .dump-splices file. ++ ++ ++ ++ The flag -dth-dec-file shows the expansions of all top-level TH declaration splices, both typed and untyped, in the file M.th.hs where M is the name of the module being compiled. ++ Note that other types of splices (expressions, types, and patterns) are not shown. ++ Application developers can check this into their repository so that they can grep for identifiers that were defined in Template Haskell. ++ This is similar to using with but it always generates a file instead of being coupled to . The format is also different: it does not show code from the original file, instead it only shows generated code and has a comment for the splice location of the original file. ++ ++ ++ ++ Below is a sample output of -ddump-splices ++ ++ ++ ++TH_pragma.hs:(6,4)-(8,26): Splicing declarations ++ [d| foo :: Int -> Int ++ foo x = x + 1 |] ++======> ++ foo :: Int -> Int ++ foo x = (x + 1) ++ ++ ++ ++ Below is the output of the same sample using -dth-dec-file ++ ++ ++ ++-- TH_pragma.hs:(6,4)-(8,26): Splicing declarations ++foo :: Int -> Int ++foo x = (x + 1) ++ ++ ++ + A Template Haskell Worked Example + To help you get over the confidence barrier, try out this skeletal worked example. + First cut and paste the two modules below into "Main.hs" and "Printf.hs": +@@ -8736,7 +9565,7 @@ + Quasi-quotation allows patterns and expressions to be written using + programmer-defined concrete syntax; the motivation behind the extension and + several examples are documented in +-"Why It's ++"Why It's + Nice to be Quoted: Quasiquoting for Haskell" (Proc Haskell Workshop + 2007). The example below shows how to write a quasiquoter for a simple + expression language. +@@ -8748,8 +9577,8 @@ + [quoter| string |]. + + +-The quoter must be the (unqualified) name of an imported +-quoter; it cannot be an arbitrary expression. ++The quoter must be the name of an imported quoter, ++either qualified or unqualified; it cannot be an arbitrary expression. + + + The quoter cannot be "e", +@@ -8942,7 +9771,7 @@ + + + +-“Programming with Arrows”, ++“Programming with Arrows”, + John Hughes, in 5th International Summer School on + Advanced Functional Programming, + Lecture Notes in Computer Science vol. 3622, +@@ -9710,6 +10539,129 @@ + + + ++ ++ ++ ++Static pointers ++<indexterm><primary>Static pointers</primary></indexterm> ++ ++ ++ ++The language extension -XStaticPointers adds a new ++syntactic form static e, ++which stands for a reference to the closed expression ++e. This reference is stable and portable, ++in the sense that it remains valid across different processes on ++possibly different machines. Thus, a process can create a reference ++and send it to another process that can resolve it to ++e. ++ ++ ++With this extension turned on, static is no longer ++a valid identifier. ++ ++ ++Static pointers were first proposed in the paper ++Towards Haskell in the cloud, Jeff Epstein, Andrew P. Black and Simon ++Peyton-Jones, Proceedings of the 4th ACM Symposium on Haskell, pp. ++118-129, ACM, 2011. ++ ++ ++ ++Using static pointers ++ ++ ++Each reference is given a key which can be used to locate it at runtime with ++unsafeLookupStaticPtr ++which uses a global and immutable table called the Static Pointer Table. ++The compiler includes entries in this table for all static forms found in ++the linked modules. The value can be obtained from the reference via ++deRefStaticPtr ++ ++ ++ ++The body e of a static ++e expression must be a closed expression. That is, there can ++be no free variables occurring in e, i.e. lambda- ++or let-bound variables bound locally in the context of the expression. ++ ++ ++ ++All of the following are permissible: ++ ++inc :: Int -> Int ++inc x = x + 1 ++ ++ref1 = static 1 ++ref2 = static inc ++ref3 = static (inc 1) ++ref4 = static ((\x -> x + 1) (1 :: Int)) ++ref5 y = static (let x = 1 in x) ++ ++While the following definitions are rejected: ++ ++ref6 = let x = 1 in static x ++ref7 y = static (let x = 1 in y) ++ ++ ++ ++ ++ ++Static semantics of static pointers ++ ++ ++ ++Informally, if we have a closed expression ++ ++e :: forall a_1 ... a_n . t ++ ++the static form is of type ++ ++static e :: (Typeable a_1, ... , Typeable a_n) => StaticPtr t ++ ++Furthermore, type t is constrained to have a ++Typeable instance. ++ ++The following are therefore illegal: ++ ++static show -- No Typeable instance for (Show a => a -> String) ++static Control.Monad.ST.runST -- No Typeable instance for ((forall s. ST s a) -> a) ++ ++ ++That being said, with the appropriate use of wrapper datatypes, the ++above limitations induce no loss of generality: ++ ++{-# LANGUAGE ConstraintKinds #-} ++{-# LANGUAGE DeriveDataTypeable #-} ++{-# LANGUAGE ExistentialQuantification #-} ++{-# LANGUAGE Rank2Types #-} ++{-# LANGUAGE StandaloneDeriving #-} ++{-# LANGUAGE StaticPointers #-} ++ ++import Control.Monad.ST ++import Data.Typeable ++import GHC.StaticPtr ++ ++data Dict c = c => Dict ++ deriving Typeable ++ ++g1 :: Typeable a => StaticPtr (Dict (Show a) -> a -> String) ++g1 = static (\Dict -> show) ++ ++data Rank2Wrapper f = R2W (forall s. f s) ++ deriving Typeable ++newtype Flip f a s = Flip { unFlip :: f s a } ++ deriving Typeable ++ ++g2 :: Typeable a => StaticPtr (Rank2Wrapper (Flip ST a) -> a) ++g2 = static (\(R2W f) -> runST (unFlip f)) ++ ++ ++ ++ ++ ++ + + + +@@ -9909,11 +10861,11 @@ + A comma denotes conjunction, i.e. both sides are required. + Conjunction binds stronger than disjunction. + +- If no MINIMAL pragma is given in the class declaration, it is just as if ++ If no MINIMAL pragma is given in the class declaration, it is just as if + a pragma {-# MINIMAL op1, op2, ..., opn #-} was given, where +- the opi are the methods +- (a) that lack a default method in the class declaration, and +- (b) whose name that does not start with an underscore ++ the opi are the methods ++ (a) that lack a default method in the class declaration, and ++ (b) whose name that does not start with an underscore + (c.f. , ). + + This warning can be turned off with the flag . +@@ -10229,6 +11181,11 @@ + 42 in the original. GHC will adjust its error messages to refer + to the line/file named in the LINE + pragma. ++ ++ LINE pragmas generated from Template Haskell set ++ the file and line position for the duration of the splice and are limited ++ to the splice. Note that because Template Haskell splices abstract syntax, ++ the file positions are not automatically advanced. + + + +@@ -10568,6 +11525,23 @@ + + + ++ ++OVERLAPPING, OVERLAPPABLE, OVERLAPS, and INCOHERENT pragmas ++ ++The pragmas ++ OVERLAPPING, ++ OVERLAPPABLE, ++ OVERLAPS, ++ INCOHERENT are used to specify the overlap ++behavior for individual instances, as described in Section ++. The pragmas are written immediately ++after the instance keyword, like this: ++ ++ ++instance {-# OVERLAPPING #-} C t where ... ++ ++ ++ + + + +@@ -10844,8 +11818,8 @@ + + + +- +-How rules interact with INLINE/NOINLINE and CONLIKE pragmas ++ ++How rules interact with INLINE/NOINLINE pragmas + + + Ordinary inlining happens at the same time as rule rewriting, which may lead to unexpected +@@ -10871,7 +11845,14 @@ + The way to get predictable behaviour is to use a NOINLINE + pragma, or an INLINE[phase] pragma, on f, to ensure + that it is not inlined until its RULEs have had a chance to fire. ++The warning flag (see ) ++warns about this situation. + ++ ++ ++ ++How rules interact with CONLIKE pragmas ++ + + GHC is very cautious about duplicating work. For example, consider + +@@ -11216,69 +12197,6 @@ + + + +- +- CORE pragma +- +- CORE pragma +- pragma, CORE +- core, annotation +- +- +- The external core format supports Note annotations; +- the CORE pragma gives a way to specify what these +- should be in your Haskell source code. Syntactically, core +- annotations are attached to expressions and take a Haskell string +- literal as an argument. The following function definition shows an +- example: +- +- +-f x = ({-# CORE "foo" #-} show) ({-# CORE "bar" #-} x) +- +- +- Semantically, this is equivalent to: +- +- +-g x = show x +- +- +- +- +- However, when external core is generated (via +- ), there will be Notes attached to the +- expressions show and x. +- The core function declaration for f is: +- +- +- +- f :: %forall a . GHCziShow.ZCTShow a -> +- a -> GHCziBase.ZMZN GHCziBase.Char = +- \ @ a (zddShow::GHCziShow.ZCTShow a) (eta::a) -> +- (%note "foo" +- %case zddShow %of (tpl::GHCziShow.ZCTShow a) +- {GHCziShow.ZCDShow +- (tpl1::GHCziBase.Int -> +- a -> +- GHCziBase.ZMZN GHCziBase.Char -> GHCziBase.ZMZN GHCziBase.Cha +-r) +- (tpl2::a -> GHCziBase.ZMZN GHCziBase.Char) +- (tpl3::GHCziBase.ZMZN a -> +- GHCziBase.ZMZN GHCziBase.Char -> GHCziBase.ZMZN GHCziBase.Cha +-r) -> +- tpl2}) +- (%note "bar" +- eta); +- +- +- +- Here, we can see that the function show (which +- has been expanded out to a case expression over the Show dictionary) +- has a %note attached to it, as does the +- expression eta (which used to be called +- x). +- +- +- +- + + + +@@ -11294,6 +12212,10 @@ + lazy + restrains the strictness analyser. + ++ ++oneShot ++gives a hint to the compiler about how often a function is being called. ++ + + + +@@ -11317,8 +12239,9 @@ + + + Using a combination of +-() and ++(), + (), ++and (), + you can easily do datatype-generic + programming using the GHC.Generics framework. This section + gives a very brief overview of how to do it. +@@ -11494,6 +12417,10 @@ + The default method for put is then used, corresponding to the + generic implementation of serialization. + ++If you are using , the same instance is ++generated by simply attaching a deriving Serialize clause ++to the UserTree datatype declaration. ++ + For more examples of generic functions please refer to the + generic-deriving + package on Hackage. +@@ -11572,7 +12499,7 @@ + url="http://www.seas.upenn.edu/~sweirich/papers/popl163af-weirich.pdf">Generative + type abstraction and type-level computation, published at POPL 2011. + +- ++ + Nominal, Representational, and Phantom + + The goal of the roles system is to track when two types have the same +@@ -11629,7 +12556,7 @@ + + + +- ++ + Role inference + + +@@ -11683,7 +12610,7 @@ + + + +- ++ + Role annotations + <indexterm><primary>-XRoleAnnotations</primary></indexterm> + +@@ -11733,14 +12660,18 @@ + + + Role annotations can also be used should a programmer wish to write +-a class with a representational (or phantom) role. ++a class with a representational (or phantom) role. However, as a class ++with non-nominal roles can quickly lead to class instance incoherence, ++it is necessary to also specify ++to allow non-nominal roles for classes. + + The other place where role annotations may be necessary are in + hs-boot files (), where + the right-hand sides of definitions can be omitted. As usual, the + types/classes declared in an hs-boot file must match up + with the definitions in the hs file, including down to the +-roles. The default role is representational in hs-boot files, ++roles. The default role for datatypes ++is representational in hs-boot files, + corresponding to the common use case. + + +@@ -11769,7 +12700,7 @@ + type role T4 nominal + data T4 a = MkT4 (a Int) -- OK, but nominal is higher than necessary + +- type role C representational _ ++ type role C representational _ -- OK, with -XIncoherentInstances + class C a b where ... -- OK, b will get a nominal role + + type role X nominal +diff -urd 7.8.2-original/gone_wrong.xml original/gone_wrong.xml +--- 7.8.2-original/gone_wrong.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/gone_wrong.xml 2016-04-09 21:36:11.394998369 +0900 +@@ -146,7 +146,7 @@ + must be re-compiled. + + A useful option to alert you when interfaces change is +- -hi-diffs ++ -ddump-hi-diffs + option. It will run + diff on the changed interface file, + before and after, when applicable. +@@ -167,7 +167,7 @@ + + + % rm *.o # scrub your object files +-% make my_prog # re-make your program; use -hi-diffs to highlight changes; ++% make my_prog # re-make your program; use -ddump-hi-diffs to highlight changes; + # as mentioned above, use -dcore-lint to be more paranoid + % ./my_prog ... # retry... + +diff -urd 7.8.2-original/intro.xml original/intro.xml +--- 7.8.2-original/intro.xml 2014-04-10 22:34:21.000000000 +0900 ++++ original/intro.xml 2016-04-09 21:36:11.394998369 +0900 +@@ -309,6 +309,7 @@ + + &relnotes1; + &relnotes2; ++&relnotes3; + + + +diff -urd 7.8.2-original/packages.xml original/packages.xml +--- 7.8.2-original/packages.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/packages.xml 2016-04-09 21:36:11.394998369 +0900 +@@ -23,7 +23,7 @@ + automates the process of configuring, building, installing and distributing + a package. All you need to do is write a simple configuration file, put a + few files in the right places, and you have a package. See the +- Cabal documentation ++ Cabal documentation + for details, and also the Cabal libraries (Distribution.Simple, + for example). + +@@ -88,7 +88,11 @@ + to expose a hidden package or hide an exposed one. Only modules + from exposed packages may be imported by your Haskell code; if + you try to import a module from a hidden package, GHC will emit +- an error message. ++ an error message. If there are a multiple exposed versions of a package, ++ GHC will prefer the latest one. Additionally, some packages may be ++ broken: that is, they are missing from the package database, or one of ++ their dependencies are broken; in this case; these packages are excluded ++ from the default set of packages. + + + +@@ -137,8 +141,11 @@ + (e.g. network-1.0) or the version + number can be omitted if there is only one version of the + package installed. If there are multiple versions +- of P installed, then all other +- versions will become hidden. ++ of P installed and ++ was not specified, then all ++ other versions will become hidden. ++ supports thinning and renaming described in . + + The + option also causes package P to +@@ -183,10 +190,12 @@ + + + Exposes a package like , but the +- package is named by its ID rather than by name. This is a ++ package is named by its installed package ID rather than by name. This is a + more robust way to name packages, and can be used to + select packages that would otherwise be shadowed. Cabal + passes flags to GHC. ++ supports thinning and renaming ++ described in . + + + +@@ -258,19 +267,15 @@ + + + +- foo +- ++ foo ++ + + + Tells GHC the the module being compiled forms part of +- package foo. ++ package key foo; internally, these ++ keys are used to determine type equality and linker symbols. + If this flag is omitted (a very common case) then the + default package main is assumed. +- Note: the argument to +- should be the full +- package name-version for the package. +- For example: +- -package mypkg-1.2. + + + +@@ -328,7 +333,7 @@ + + Every complete Haskell program must define main in + module Main +- in package main. (Omitting the flag compiles ++ in package main. (Omitting the flag compiles + code for package main.) Failure to do so leads to a somewhat obscure + link-time error of the form: + +@@ -367,6 +372,53 @@ + name. + + ++ ++ Thinning and renaming modules ++ ++ When incorporating packages from multiple sources, you may end up ++ in a situation where multiple packages publish modules with the same name. ++ Previously, the only way to distinguish between these modules was to ++ use . However, since GHC 7.10, ++ the flags (and their variants) have been extended ++ to allow a user to explicitly control what modules a package brings into ++ scope, by analogy to the import lists that users can attach to module imports. ++ ++ ++ ++ The basic syntax is that instead of specifying a package name P to the package ++ flag -package, instead we specify both a package name and a ++ parenthesized, comma-separated list of module names to import. For example, ++ -package "base (Data.List, Data.Bool)" makes only ++ Data.List and Data.Bool visible from ++ package base. We also support renaming of modules, in case ++ you need to refer to both modules simultaneously; this is supporting by ++ writing OldModName as NewModName, e.g. -package ++ "base (Data.Bool as Bool). You can also write -package ++ "base with (Data.Bool as Bool) to include all of the original ++ bindings (e.g. the renaming is strictly additive). It's important to specify ++ quotes so that your shell passes the package name and thinning/renaming list ++ as a single argument to GHC. ++ ++ Package imports with thinning/renaming do not hide other versions of the ++ package: e.g. if containers-0.9 is already exposed, -package ++ "containers-0.8 (Data.List as ListV8)" will only add an additional ++ binding to the environment. Similarly, -package "base (Data.Bool as ++ Bool)" -package "base (Data.List as List)" is equivalent to ++ -package "base (Data.Bool as Bool, Data.List as List)". ++ Literal names must refer to modules defined by the original package, so for ++ example -package "base (Data.Bool as Bool, Bool as Baz)" is ++ invalid unless there was a Bool module defined in the ++ original package. Hiding a package also clears all of its renamings. ++ ++ ++ You can use renaming to provide an alternate prelude, e.g. ++ -hide-all-packages -package "basic-prelude (BasicPrelude as ++ Prelude)", in lieu of the NoImplicitPrelude extension. ++ ++ ++ ++ + + Package Databases + +@@ -528,12 +580,11 @@ + + + +- Package IDs, dependencies, and broken packages ++ Installed package IDs, dependencies, and broken packages + + Each installed package has a unique identifier (the +- “installed package ID”, or just “package +- ID” for short) , which distinguishes it from all other +- installed packages on the system. To see the package IDs ++ “installed package ID”), which distinguishes it from all other ++ installed packages on the system. To see the installed package IDs + associated with each installed package, use ghc-pkg + list -v: + +@@ -549,10 +600,10 @@ + + + +- The string in parentheses after the package name is the package ++ The string in parentheses after the package name is the installed package + ID: it normally begins with the package name and version, and + ends in a hash string derived from the compiled package. +- Dependencies between packages are expressed in terms of package ++ Dependencies between packages are expressed in terms of installed package + IDs, rather than just packages and versions. For example, take + a look at the dependencies of the haskell98 + package: +@@ -570,14 +621,14 @@ + + + +- The purpose of the package ID is to detect problems caused by ++ The purpose of the installed package ID is to detect problems caused by + re-installing a package without also recompiling the packages + that depend on it. Recompiling dependencies is necessary, + because the newly compiled package may have a different ABI + (Application Binary Interface) than the previous version, even + if both packages were built from the same source code using the +- same compiler. With package IDs, a recompiled +- package will have a different package ID from the previous ++ same compiler. With installed package IDs, a recompiled ++ package will have a different installed package ID from the previous + version, so packages that depended on the previous version are + now orphaned - one of their dependencies is not satisfied. + Packages that are broken in this way are shown in +@@ -691,7 +742,9 @@ + package; the specified action will be applied to all the matching + packages. A package specifier that matches all version of the package + can also be written pkg-*, +- to make it clearer that multiple packages are being matched. ++ to make it clearer that multiple packages are being matched. To match ++ against the installed package ID instead of just package name and version, ++ pass the flag. + + + +@@ -1047,8 +1100,25 @@ + Output the ghc-pkg version number. + + +- + ++ ++ ++ ++ ++ ++ ++ ++ ++ Causes ghc-pkg to interpret arguments ++ as installed package IDs (e.g., an identifier like ++ unix-2.3.1.0-de7803f1a8cd88d2161b29b083c94240 ++ ). This is useful if providing just the package ++ name and version are ambiguous (in old versions of GHC, this ++ was guaranteed to be unique, but this invariant no longer ++ necessarily holds). ++ ++ ++ + + + +@@ -1057,7 +1127,7 @@ + building + + We don't recommend building packages the hard way. Instead, use the +- Cabal infrastructure ++ Cabal infrastructure + if possible. If your package is particularly complicated or requires a + lot of configuration, then you might have to fall back to the low-level + mechanisms, so a few hints for those brave souls follow. +@@ -1152,8 +1222,8 @@ + + + To compile a module which is to be part of a new package, +- use the -package-name option (). +- Failure to use the -package-name option ++ use the -this-package-key option (). ++ Failure to use the -this-package-key option + when compiling a package will probably result in disaster, but + you will only discover later when you attempt to import modules + from the package. At this point GHC will complain that the +@@ -1288,7 +1358,7 @@ + idpackage specification + + +- The package ID. It is up to you to choose a suitable ++ The installed package ID. It is up to you to choose a suitable + one. + + +@@ -1447,6 +1517,25 @@ + + + ++ reexported-modules ++ reexported-modulesreexport specification ++ ++ ++ Modules reexported by this package. This list takes ++ the form of pkg:OldName as NewName ++ (A@orig-pkg-0.1-HASH): the first portion of the ++ string is the user-written reexport specification (possibly ++ omitting the package qualifier and the renaming), while the ++ parenthetical is the original package which exposed the ++ module under are particular name. Reexported modules have ++ a relaxed overlap constraint: it's permissible for two ++ packages to reexport the same module as the same name if the ++ reexported moduleis identical. ++ ++ ++ ++ ++ + trusted + trustedpackage specification + +@@ -1723,6 +1812,92 @@ + --> + + ++ ++ package environments ++ ++ Package environments ++ ++ ++ A package environment is a file that tells ++ ghc precisely which packages should be visible. It ++ contains package IDs, one per line: ++ ++ ++package_id_1 ++package_id_2 ++... ++package_id_n ++ ++ ++ If a package environment is found, it is equivalent to passing these ++ command line arguments to ghc: ++ ++ ++-hide-all-packages ++-package-id package_id_1 ++-package-id package_id_2 ++... ++-package-id package_id_n ++ ++ ++ In order, ghc will look for the package environment ++ in the following locations: ++ ++ ++ ++ ++ File ++ file ++ if you pass the option ++ . ++ ++ ++ ++ ++ File ++ $HOME/.ghc/arch-os-version/environments/name ++ if you pass the option ++ . ++ ++ ++ ++ ++ File ++ file ++ if the environment variable GHC_ENVIRONMENT ++ is set to file. ++ ++ ++ ++ ++ File ++ $HOME/.ghc/arch-os-version/environments/name ++ if the environment variable GHC_ENVIRONMENT ++ is set to name. ++ ++ ++ ++ ++ File ./.ghc.environment if it exists. ++ ++ ++ ++ ++ File ++ $HOME/.ghc/arch-os-version/environments/default ++ if it exists. ++ ++ ++ ++ ++ Package environments can be modified by further command line arguments; ++ for example, if you specify ++ ++ on the command line, then package foo will be ++ visible even if it's not listed in the currently active package ++ environment. ++ ++ + + + +- + + You might also want to take a look +@@ -1771,7 +1771,7 @@ + + Because ticky-ticky profiling requires a certain familiarity + with GHC internals, we have moved the documentation to the +- wiki. Take a look at its overview + of the profiling options, which includeds a link to the + ticky-ticky profiling page. +diff -urd 7.8.2-original/runtime_control.xml original/runtime_control.xml +--- 7.8.2-original/runtime_control.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/runtime_control.xml 2016-04-09 21:36:11.395998334 +0900 +@@ -323,6 +323,26 @@ + + + ++ ++ ++ ++ RTS ++ option ++ ++ ++ [Default: 100k] This option relates to allocation ++ limits; for more about this see enableAllocationLimit. ++ When a thread hits its allocation limit, the RTS throws an ++ exception to the thread, and the thread gets an additional ++ quota of allocation before the exception is raised again, ++ the idea being so that the thread can execute its exception ++ handlers. The controls the size of ++ this additional quota. ++ ++ ++ ++ + + + +@@ -365,6 +385,42 @@ + + + ++ ++ size ++ RTS option ++ allocation area, chunk size ++ ++ ++ [Default: 0, Example: ++ -n4m] When set to a non-zero value, ++ this option divides the allocation area ( ++ value) into chunks of the specified size. During execution, ++ when a processor exhausts its current chunk, it is given ++ another chunk from the pool until the pool is exhausted, at ++ which point a collection is triggered. ++ ++ This option is only useful when running in parallel ++ ( or greater). It allows the processor ++ cores to make better use of the available allocation area, ++ even when cores are allocating at different rates. Without ++ , each core gets a fixed-size allocation ++ area specified by the , and the first ++ core to exhaust its allocation area triggers a GC across all ++ the cores. This can result in a collection happening when ++ the allocation areas of some cores are only partially full, ++ so the purpose of the is to allow cores ++ that are allocating faster to get more of the allocation ++ area. This means less frequent GC, leading a lower GC ++ overhead for the same heap size. ++ ++ This is particularly useful in conjunction with larger ++ values, for example is a useful combination on larger core counts ++ (8+). ++ ++ ++ ++ + + + RTS option +@@ -1442,8 +1498,7 @@ + -threaded option) and rts_p + (profiling runtime, i.e. linked using the -prof + option). Other variants include debug +- (linked using -debug), +- t (ticky-ticky profiling) and ++ (linked using -debug), and + dyn (the RTS is + linked in dynamically, i.e. a shared library, rather than statically + linked into the executable itself). These can be combined, +diff -urd 7.8.2-original/safe_haskell.xml original/safe_haskell.xml +--- 7.8.2-original/safe_haskell.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/safe_haskell.xml 2016-04-09 21:36:11.394998369 +0900 +@@ -705,7 +705,7 @@ + + + +- And two warning flags: ++ And three warning flags: + + + +@@ -724,6 +724,15 @@ + when using safe inference. + + ++ ++ -fwarn-trustworthy-safe ++ -fwarn-trustworthy-safe ++ Issue a warning if the module being compiled is marked as ++ but it could instead be marked as ++ , a more informative bound. Can be used to ++ detect once a Safe Haskell bound can be improved as dependencies are ++ updated. ++ + + + +@@ -767,6 +776,12 @@ + Wiki. + + ++ ++ Additionally, the use of annotations ++ is forbidden, as that would allow bypassing Safe Haskell restrictions. ++ See ticket #10826. ++ ++ + + + +diff -urd 7.8.2-original/separate_compilation.xml original/separate_compilation.xml +--- 7.8.2-original/separate_compilation.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/separate_compilation.xml 2016-04-09 21:36:11.395998334 +0900 +@@ -883,6 +883,100 @@ + + + ++ ++ Module signatures ++ GHC supports the specification of module signatures, which ++ both implementations and users can typecheck against separately. ++ This functionality should be considered experimental for now; some ++ details, especially for type classes and type families, may change. ++ This system was originally described in Backpack: Retrofitting Haskell with ++ Interfaces. Signature files are somewhat similar to ++ hs-boot files, but have the hsig ++ extension and behave slightly differently. ++ ++ ++ Suppose that I have modules String.hs and ++ A.hs, thus: ++ ++ ++module Text where ++ data Text = Text String ++ ++ empty :: Text ++ empty = Text "" ++ ++ toString :: Text -> String ++ toString (Text s) = s ++ ++module A where ++ import Text ++ z = toString empty ++ ++ ++ Presently, module A depends explicitly on ++ a concrete implementation of Text. What if we wanted ++ to a signature Text, so we could vary the ++ implementation with other possibilities (e.g. packed UTF-8 encoded ++ bytestrings)? To do this, we can write a signature ++ TextSig.hsig, and modify A ++ to include the signature instead: ++ ++ ++ ++module TextSig where ++ data Text ++ empty :: Text ++ toString :: Text -> String ++ ++module A where ++ import TextSig ++ z = toString empty ++ ++ ++ To compile these two files, we need to specify what module we ++ would like to use to implement the signature. This can be done by ++ compiling the implementation, and then using the -sig-of ++ flag to specify the implementation backing a signature: ++ ++ ++ghc -c Text.hs ++ghc -c TextSig.hsig -sig-of main:Text ++ghc -c A.hs ++ ++ ++ Signature files can also be compiled as part of ++ --make, in which case the syntax is extended ++ to support specifying implementations of multiple signatures ++ as FooSig is main:Foo, BarSig is main:Bar. ++ At the moment, you must specify the full module name (package key, ++ colon, and then module name), although in the future we may support ++ more user-friendly syntax. ++ ++ To just type-check an interface file, no -sig-of ++ is necessary; instead, just pass the options ++ -fno-code -fwrite-interface. hsig ++ files will generate normal interface files which other files can ++ also use to type-check against. However, at the moment, we always ++ assume that an entity defined in a signature is a unique identifier ++ (even though we may happen to know it is type equal with another ++ identifier). In the future, we will support passing shaping information ++ to the compiler in order to let it know about these type ++ equalities. ++ ++ Just like hs-boot files, when an ++ hsig file is compiled it is checked for type ++ consistency against the backing implementation. Signature files are also ++ written in a subset of Haskell essentially identical to that of ++ hs-boot files. ++ ++ There is one important gotcha with the current implementation: ++ currently, instances from backing implementations will "leak" code that ++ uses signatures, and explicit instance declarations in signatures are ++ forbidden. This behavior will be subject to change. ++ ++ ++ + + + Using <command>make</command> +diff -urd 7.8.2-original/ug-book.xml original/ug-book.xml +--- 7.8.2-original/ug-book.xml 2014-06-27 09:31:23.000000000 +0900 ++++ original/ug-book.xml 2016-04-09 21:36:11.395998334 +0900 +@@ -1,6 +1,6 @@ + + +-The Glorious Glasgow Haskell Compilation System User's Guide, Version 7.8.2 ++The Glorious Glasgow Haskell Compilation System User's Guide, Version 7.10.3 + The GHC Team +
+ glasgow-haskell-users-request@haskell.org +@@ -17,7 +17,6 @@ + &lang-features; + &ffi-chap; + &extending-ghc; +-&external-core; + &wrong; + &utils; + &win32-dll; +diff -urd 7.8.2-original/ug-book.xml.in original/ug-book.xml.in +--- 7.8.2-original/ug-book.xml.in 2014-04-08 03:26:08.000000000 +0900 ++++ original/ug-book.xml.in 2016-04-09 21:36:11.395998334 +0900 +@@ -17,7 +17,6 @@ + &lang-features; + &ffi-chap; + &extending-ghc; +-&external-core; + &wrong; + &utils; + &win32-dll; +diff -urd 7.8.2-original/ug-ent.xml original/ug-ent.xml +--- 7.8.2-original/ug-ent.xml 2014-06-27 09:31:23.000000000 +0900 ++++ original/ug-ent.xml 2016-04-09 21:36:11.395998334 +0900 +@@ -3,8 +3,9 @@ + + + +- +- ++ ++ ++ + + + +@@ -13,7 +14,6 @@ + + + +- + + + +@@ -27,7 +27,7 @@ + + + +- +- +- ++ ++ ++ + +diff -urd 7.8.2-original/ug-ent.xml.in original/ug-ent.xml.in +--- 7.8.2-original/ug-ent.xml.in 2014-04-10 22:34:06.000000000 +0900 ++++ original/ug-ent.xml.in 2016-04-09 21:36:11.395998334 +0900 +@@ -3,8 +3,9 @@ + + + +- +- ++ ++ ++ + + + +@@ -13,7 +14,6 @@ + + + +- + + + +original のみに存在: users_guide +diff -urd 7.8.2-original/using.xml original/using.xml +--- 7.8.2-original/using.xml 2014-04-08 03:26:08.000000000 +0900 ++++ original/using.xml 2016-04-09 21:36:11.394998369 +0900 +@@ -246,6 +246,13 @@ + + + ++ .hspp ++ ++ A file created by the preprocessor. ++ ++ ++ ++ + .hi + + A Haskell interface file, probably +@@ -383,7 +390,7 @@ + + + ghc -E +- ghc -c ++ ghc -C + ghc -S + ghc -c + +@@ -395,10 +402,7 @@ + + This is the traditional batch-compiler mode, in which + GHC can compile source files one at a time, or link objects +- together into an executable. This mode also applies if +- there is no other mode flag specified on the command line, +- in which case it means that the specified files should be +- compiled and then linked to form a program. See . + + +@@ -617,6 +621,11 @@ + given on the command line and GHC will include them when linking + the executable. + ++ For backward compatibility with existing make scripts, when ++ used in combination with , the linking phase ++ is omitted (same as ++ ). ++ + Note that GHC can only follow dependencies if it has the + source file available, so if your program includes a module for + which there is no source file, even if you have an object and an +@@ -765,6 +774,10 @@ + option runs just the pre-processing passes + of the compiler, dumping the result in a file. + ++ Note: The option is only available when ++ GHC is built in unregisterised mode. See ++ for more details. ++ + + Overriding the default behaviour for a file + +@@ -899,20 +912,38 @@ + ghci> :t f + f :: forall a. a -> a + +- Using makes GHC print kind-foralls and kind applications ++However, regardless of the flag setting, the quantifiers are printed under these circumstances: ++ ++For nested foralls, e.g. ++ ++ghci> :t GHC.ST.runST ++GHC.ST.runST :: (forall s. GHC.ST.ST s a) -> a ++ ++ ++If any of the quantified type variables has a kind ++that mentions a kind variable, e.g. ++ ++ghci> :i Data.Type.Equality.sym ++Data.Type.Equality.sym :: ++ forall (k :: BOX) (a :: k) (b :: k). ++ (a Data.Type.Equality.:~: b) -> b Data.Type.Equality.:~: a ++ -- Defined in Data.Type.Equality ++ ++ ++ ++ ++ ++ Using makes GHC print kind arguments + in types, which are normally suppressed. This can be important when you are using kind polymorphism. + For example: + + ghci> :set -XPolyKinds + ghci> data T a = MkT + ghci> :t MkT +-MkT :: T b ++MkT :: forall (k :: BOX) (a :: k). T a + ghci> :set -fprint-explicit-foralls + ghci> :t MkT +-MkT :: forall (b::k). T b +-ghci> :set -fprint-explicit-kinds +-ghci> :t MkT +-MkT :: forall (k::BOX) (b:k). T b ++MkT :: forall (k :: BOX) (a :: k). T k a + + + +@@ -1003,7 +1034,6 @@ + program. These are: + , + , +- , + , + , + , +@@ -1016,8 +1046,10 @@ + , + , + , +- , and +- . ++ , ++ , ++ , and ++ . + The following flags are simple ways to select standard + “packages” of warnings: + +@@ -1029,12 +1061,12 @@ + + -W option + Provides the standard warnings plus +- , +- , +- , ++ , + , +- , and +- . ++ , ++ , ++ , and ++ . + + + +@@ -1046,14 +1078,15 @@ + suspicious code. The warnings that are + not enabled by + are +- , + , + , + , + , + , + , +- . ++ , ++ and ++ . + + + +@@ -1099,14 +1132,11 @@ + + + warnings +- When the compiler encounters an unbound local +- variable prefixed with _, or encounters +- the literal _ on the right-hand side of +- an expression, the error message for the unbound term +- includes the type it needs to type check. It works +- particularly well with deferred type errors. +- See ++ ++ Determines whether the compiler reports typed holes warnings. Has ++ no effect unless typed holes errors are deferred until runtime. ++ See and ++ + + This warning is on by default. + +@@ -1128,6 +1158,45 @@ + + + ++ : ++ ++ ++ ++ warnings ++ ++ Defer typed holes errors until runtime. This will turn the errors ++ produced by typed holes into ++ warnings. Using a value that depends on a typed hole produces a ++ runtime error, the same as ++ (which implies this option). See ++ and . ++ ++ ++ Implied by . See also ++ . ++ ++ ++ ++ ++ ++ : ++ ++ ++ ++ warnings ++ ++ Determines whether the compiler reports holes in partial type ++ signatures as warnings. Has no effect unless ++ is enabled, which ++ controls whether errors should be generated for holes in types ++ or not. See . ++ ++ ++ This warning is on by default. ++ ++ ++ ++ + : + + +@@ -1579,6 +1648,21 @@ + + + ++ : ++ ++ ++ type signatures, missing ++ ++ If you would like GHC to check that every exported top-level ++ function/value has a type signature, but not check unexported values, use the ++ option. This option ++ takes precedence over . ++ As part of the warning GHC also reports the inferred type. The ++ option is off by default. ++ ++ ++ ++ + : + + +@@ -1672,8 +1756,6 @@ + tabs, warning + Have the compiler warn if there are tabs in your source + file. +- +- This warning is off by default. + + + +@@ -1713,21 +1795,80 @@ + + + ++ : ++ ++ ++ promoted constructor, warning ++ Warn if a promoted data constructor is used without a tick preceding it's name. ++ ++ For example: ++ ++ ++data Nat = Succ Nat | Zero ++ ++data Vec n s where ++ Nil :: Vec Zero a ++ Cons :: a -> Vec n a -> Vec (Succ n) a ++ ++ Will raise two warnings because Zero ++ and Succ are not written as 'Zero and ++ 'Succ. ++ ++ This warning is enabled by default in -Wall mode. ++ ++ ++ ++ + : + + + unused binds, warning + binds, unused + Report any function definitions (and local bindings) +- which are unused. For top-level functions, the warning is +- only given if the binding is not exported. +- A definition is regarded as "used" if (a) it is exported, or (b) it is +- mentioned in the right hand side of another definition that is used, or (c) the +- function it defines begins with an underscore. The last case provides a +- way to suppress unused-binding warnings selectively. +- Notice that a variable +- is reported as unused even if it appears in the right-hand side of another +- unused binding. ++ which are unused. More precisely: ++ ++ ++ Warn if a binding brings into scope a variable that is not used, ++ except if the variable's name starts with an underscore. The "starts-with-underscore" ++ condition provides a way to selectively disable the warning. ++ ++ ++ A variable is regarded as "used" if ++ ++ It is exported, or ++ It appears in the right hand side of a binding that binds at ++ least one used variable that is used ++ ++ For example ++ ++module A (f) where ++f = let (p,q) = rhs1 in t p -- Warning about unused q ++t = rhs3 -- No warning: f is used, and hence so is t ++g = h x -- Warning: g unused ++h = rhs2 -- Warning: h is only used in the right-hand side of another unused binding ++_w = True -- No warning: _w starts with an underscore ++ ++ ++ ++ ++ Warn if a pattern binding binds no variables at all, unless it is a lone, possibly-banged, wild-card pattern. ++ For example: ++ ++Just _ = rhs3 -- Warning: unused pattern binding ++(_, _) = rhs4 -- Warning: unused pattern binding ++_ = rhs3 -- No warning: lone wild-card pattern ++!_ = rhs4 -- No warning: banged wild-card pattern; behaves like seq ++ ++ The motivation for allowing lone wild-card patterns is they ++ are not very different from _v = rhs3, ++ which elicits no warning; and they can be useful to add a type ++ constraint, e.g. _ = x::Int. A lone ++ banged wild-card pattern is is useful as an alternative ++ (to seq) way to force evaluation. ++ ++ ++ ++ + + + +@@ -1790,6 +1931,27 @@ + + + ++ : ++ ++ ++ implicit context quantification, warning ++ context, implicit quantification ++ ++ Report if a variable is quantified only due to its presence ++ in a context (see ). For example, ++ ++ type T a = Monad m => a -> f a ++ ++ It is recommended to write this polymorphic type as ++ ++ type T a = forall m. Monad m => a -> f a ++ ++ instead. ++ ++ ++ ++ ++ + : + + +@@ -1814,6 +1976,16 @@ + + + ++ ++ : ++ ++ ++ Warn if a rewrite RULE might fail to fire because the function might be ++ inlined before the rule has a chance to fire. See . ++ ++ ++ ++ + + + If you're feeling really paranoid, the +@@ -1922,6 +2094,21 @@ + . + + ++ ++ ++ ++ : ++ -Odph ++ optimiseDPH ++ ++ ++ Enables all optimisation, sets ++ ++ and . Designed for use with ++ Data Parallel Haskell (DPH). ++ ++ ++ + + + We don't use a flag for day-to-day +@@ -1942,40 +2129,16 @@ + -fno-* options (GHC) + + These flags turn on and off individual optimisations. +- They are normally set via the options +- described above, and as such, you shouldn't need to set any of +- them explicitly (indeed, doing so could lead to unexpected +- results). A flag can be negated by +- saying . The flags below are off +- by default, except where noted below. See +- for a compact list. ++ Flags marked as Enabled by default are ++ enabled by , and as such you shouldn't ++ need to set any of them explicitly. A flag ++ can be negated by saying . ++ See for a compact list. + + + + + +- +- +- +- +- Part of Data Parallel Haskell +- (DPH). +- +- Off by default. Enable the +- vectorisation avoidance optimisation. This +- optimisation only works when used in combination with the +- transformation. +- +- While vectorisation of code using DPH is often a big win, it +- can also produce worse results for some kinds of code. This +- optimisation modifies the vectorisation transformation to try to +- determine if a function would be better of unvectorised and if +- so, do just that. +- +- +- +- +- + + + +@@ -2000,6 +2163,56 @@ + + + ++ ++ ++ ++ ++ On by default.. ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ On by default.. Enables the common block ++ elimination optimisation in the code generator. This optimisation ++ attempts to find identical Cmm blocks and eliminate the duplicates. ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ On by default.. Enables the sinking pass ++ in the code generator. This optimisation ++ attempts to find identical Cmm blocks and eliminate the duplicates ++ attempts to move variable bindings closer to their usage sites. It ++ also inlines simple expressions like literals or registers. ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ Switch off CPR analysis in the demand analyser. ++ ++ ++ ++ ++ ++ + + + +@@ -2025,12 +2238,25 @@ + + + +- ++ + + + +- On by default. +- Eta-expand let-bindings to increase their arity. ++ Make dictionaries strict. ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ On by default for , , ++ . ++ ++ Use a special demand transformer for dictionary selectors. + + + +@@ -2050,6 +2276,18 @@ + + + ++ ++ ++ ++ ++ On by default. ++ Eta-expand let-bindings to increase their arity. ++ ++ ++ ++ ++ ++ + + + +@@ -2176,12 +2414,12 @@ + + + +- Causes GHC to ignore uses of the function ++ On by default.. ++ Causes GHC to ignore uses of the function + Exception.assert in source code (in + other words, rewriting Exception.assert p + e to e (see ). This flag is turned on by +- . ++ linkend="assertions"/>). + + + +@@ -2204,12 +2442,12 @@ + + + +- Off by default.Run demand analysis ++ Run demand analysis + again, at the end of the simplification pipeline. We found some opportunities + for discovering strictness that were not visible earlier; and optimisations like + -fspec-constr can create functions with unused arguments which + are eliminated by late demand analysis. Improvements are modest, but so is the +- cost. See notes on the Trac wiki page. ++ cost. See notes on the Trac wiki page. + + + +@@ -2232,26 +2470,78 @@ + + + +- ++ + + + +- Set the size threshold for the liberate-case transformation. ++ Set the size threshold for the liberate-case transformation. Default: 2000 + + + + + + +- ++ ++ ++ ++ ++ On by default. ++ ++ When this optimisation is enabled the code generator will turn ++ all self-recursive saturated tail calls into local jumps rather ++ than function calls. ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ Set the maximum size of inline array allocations to n bytes ++ (default: 128). GHC will allocate non-pinned arrays of statically ++ known size in the current nursery block if they're no bigger ++ than n bytes, ignoring GC overheap. This value should be quite ++ a bit smaller than the block size (typically: 4096). ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ Inline memcpy calls if they would generate no more than n pseudo instructions (default: 32). ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ Inline memset calls if they would generate no more than n pseudo instructions (default: 32). ++ ++ ++ ++ ++ ++ ++ + + + + The type checker sometimes displays a fragment of the type environment + in error messages, but only up to some maximum number, set by this flag. +- The default is 6. Turning it off with +- gives an unlimited number. Syntactically top-level bindings are also +- usually excluded (since they may be numerous), but ++ The default is 6. Turning it off with ++ gives an unlimited number. Syntactically top-level bindings are also ++ usually excluded (since they may be numerous), but + includes them too. + + +@@ -2259,6 +2549,50 @@ + + + ++ ++ ++ ++ ++ Sets the maximal number of iterations for the simplifier. Defult: 4. ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ If a worker has that many arguments, none will be unpacked anymore (default: 10) ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ Turn off the coercion optimiser. ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ Turn off pre-inlining. ++ ++ ++ ++ ++ ++ + + + +@@ -2326,11 +2660,11 @@ + + + +- ++ + + +- Off by default, but enabled by -O2. Only applies in +- combination with the native code generator. ++ Off by default due to a performance regression bug. ++ Only applies in combination with the native code generator. + Use the graph colouring register allocator for register allocation + in the native code generator. By default, GHC uses a simpler, + faster linear register allocator. The downside being that the +@@ -2342,14 +2676,14 @@ + + + +- ++ + + + Off by default, only applies in combination with + the native code generator. + Use the iterative coalescing graph colouring register allocator for + register allocation in the native code generator. This is the same +- register allocator as the one but also ++ register allocator as the one but also + enables iterative coalescing during register allocation. + + +@@ -2357,6 +2691,17 @@ + + + ++ ++ ++ ++ ++ Set the number of phases for the simplifier (default 2). Ignored with -O0. ++ ++ ++ ++ ++ ++ + + + +@@ -2385,77 +2730,6 @@ + + + +- : +- +- inlining, controlling +- unfolding, controlling +- +- +- (Default: 45) Governs the maximum size that GHC will allow a +- function unfolding to be. (An unfolding has a “size” +- that reflects the cost in terms of “code bloat” of +- expanding (aka inlining) that unfolding at a call site. A bigger +- function would be assigned a bigger cost.) +- +- +- Consequences: (a) nothing larger than this will be inlined +- (unless it has an INLINE pragma); (b) nothing larger than this +- will be spewed into an interface file. +- +- +- Increasing this figure is more likely to result in longer +- compile times than faster code. The +- is more useful. +- +- +- +- +- +- +- +- +- inlining, controlling +- unfolding, controlling +- +- +- (Default: 8) This is the magic cut-off figure for unfolding +- (aka inlining): below this size, a function definition will be +- unfolded at the call-site, any bigger and it won't. The size +- computed for a function depends on two things: the actual size of +- the expression minus any discounts that +- apply (see ). +- +- +- The difference between this and +- is that this one +- determines if a function definition will be inlined at +- a call site. The other option determines if a +- function definition will be kept around at all for potential +- inlining. +- +- +- +- +- +- +- +- +- +- +- Part of Data Parallel Haskell +- (DPH). +- +- Off by default. Enable the +- vectorisation optimisation transformation. This +- optimisation transforms the nested data parallelism code of programs +- using DPH into flat data parallelism. Flat data parallel programs +- should have better load balancing, enable SIMD parallelism and +- friendlier cache behaviour. +- +- +- +- +- + + + +@@ -2538,6 +2812,30 @@ + + + ++ ++ ++ ++ ++ Set the maximum number of specialisations ++ that will be created for any one function by the SpecConstr ++ transformation (default: 3). ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ Set the size threshold for the SpecConstr transformation (default: 2000). ++ ++ ++ ++ ++ ++ + + + +@@ -2592,25 +2890,12 @@ + + + +- : +- +- strict constructor fields +- constructor fields, strict ++ ++ + + +- This option causes all constructor fields which are marked +- strict (i.e. “!”) to be unpacked if possible. It is +- equivalent to adding an UNPACK pragma to every +- strict constructor field (see ). ++ Run an additional strictness analysis before simplifier phase n. + +- +- This option is a bit of a sledgehammer: it might sometimes +- make things worse. Selectively unboxing fields by using +- UNPACK pragmas might be better. An alternative +- is to use to turn on +- unboxing by default but disable it for certain constructor +- fields using the NOUNPACK pragma (see +- ). + + + +@@ -2662,6 +2947,162 @@ + + + ++ ++ ++ : ++ ++ strict constructor fields ++ constructor fields, strict ++ ++ ++ This option causes all constructor fields which are marked ++ strict (i.e. “!”) to be unpacked if possible. It is ++ equivalent to adding an UNPACK pragma to every ++ strict constructor field (see ). ++ ++ ++ This option is a bit of a sledgehammer: it might sometimes ++ make things worse. Selectively unboxing fields by using ++ UNPACK pragmas might be better. An alternative ++ is to use to turn on ++ unboxing by default but disable it for certain constructor ++ fields using the NOUNPACK pragma (see ++ ). ++ ++ ++ ++ ++ ++ : ++ ++ inlining, controlling ++ unfolding, controlling ++ ++ ++ (Default: 750) Governs the maximum size that GHC will allow a ++ function unfolding to be. (An unfolding has a “size” ++ that reflects the cost in terms of “code bloat” of ++ expanding (aka inlining) that unfolding at a call site. A bigger ++ function would be assigned a bigger cost.) ++ ++ ++ Consequences: (a) nothing larger than this will be inlined ++ (unless it has an INLINE pragma); (b) nothing larger than this ++ will be spewed into an interface file. ++ ++ ++ Increasing this figure is more likely to result in longer ++ compile times than faster code. The ++ is more useful. ++ ++ ++ ++ ++ ++ ++ : ++ ++ inlining, controlling ++ unfolding, controlling ++ ++ ++ Default: 30 ++ ++ ++ ++ ++ ++ ++ : ++ ++ inlining, controlling ++ unfolding, controlling ++ ++ ++ Default: 60 ++ ++ ++ ++ ++ ++ ++ : ++ ++ inlining, controlling ++ unfolding, controlling ++ ++ ++ Default: 1.5 ++ ++ ++ ++ ++ ++ ++ ++ ++ inlining, controlling ++ unfolding, controlling ++ ++ ++ (Default: 60) This is the magic cut-off figure for unfolding ++ (aka inlining): below this size, a function definition will be ++ unfolded at the call-site, any bigger and it won't. The size ++ computed for a function depends on two things: the actual size of ++ the expression minus any discounts that apply depending on the ++ context into which the expression is to be inlined. ++ ++ ++ The difference between this and ++ is that this one ++ determines if a function definition will be inlined at ++ a call site. The other option determines if a ++ function definition will be kept around at all for potential ++ inlining. ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ Part of Data Parallel Haskell ++ (DPH). ++ ++ On by default. Enable the ++ vectorisation avoidance optimisation. This ++ optimisation only works when used in combination with the ++ transformation. ++ ++ While vectorisation of code using DPH is often a big win, it ++ can also produce worse results for some kinds of code. This ++ optimisation modifies the vectorisation transformation to try to ++ determine if a function would be better of unvectorised and if ++ so, do just that. ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ Part of Data Parallel Haskell ++ (DPH). ++ ++ Off by default. Enable the ++ vectorisation optimisation transformation. This ++ optimisation transforms the nested data parallelism code of programs ++ using DPH into flat data parallelism. Flat data parallel programs ++ should have better load balancing, enable SIMD parallelism and ++ friendlier cache behaviour. ++ ++ ++ + + + +@@ -2819,13 +3260,29 @@ + + RTS option + Use x simultaneous threads when +- running the program. Normally x +- should be chosen to match the number of CPU cores on the +- machineWhether hyperthreading cores should be counted or not is an +- open question; please feel free to experiment and let us know what +- results you find.. For example, +- on a dual-core machine we would probably use +- +RTS -N2 -RTS. ++ running the program. ++ ++ The runtime manages a set of virtual processors, ++ which we call capabilities, the ++ number of which is determined by the ++ option. Each capability can run one Haskell thread at a ++ time, so the number of capabilities is equal to the ++ number of Haskell threads that can run physically in ++ parallel. A capability is animated by one or more OS ++ threads; the runtime manages a pool of OS threads for ++ each capability, so that if a Haskell thread makes a ++ foreign call (see ) ++ another OS thread can take over that capability. ++ ++ ++ Normally x should be ++ chosen to match the number of CPU cores on the ++ machineWhether hyperthreading cores ++ should be counted or not is an open question; please ++ feel free to experiment and let us know what results you ++ find.. For example, on a dual-core ++ machine we would probably use +RTS -N2 ++ -RTS. + + Omitting x, + i.e. +RTS -N -RTS, lets the runtime +@@ -2842,10 +3299,11 @@ + ). + + The current value of the option +- is available to the Haskell program +- via Control.Concurrent.getNumCapabilities, and +- it may be changed while the program is running by +- calling Control.Concurrent.setNumCapabilities. ++ is available to the Haskell program via ++ Control.Concurrent.getNumCapabilities, ++ and it may be changed while the program is running by ++ calling ++ Control.Concurrent.setNumCapabilities. + + + +@@ -2860,9 +3318,18 @@ + option + + Use the OS's affinity facilities to try to pin OS +- threads to CPU cores. This is an experimental feature, +- and may or may not be useful. Please let us know +- whether it helps for you! ++ threads to CPU cores. ++ ++ When this option is enabled, the OS threads for a ++ capability i are bound to the CPU ++ core i using the API provided by the ++ OS for setting thread affinity. e.g. on Linux ++ GHC uses sched_setaffinity(). ++ ++ Depending on your workload and the other activity on ++ the machine, this may or may not result in a performance ++ improvement. We recommend trying it out and measuring the ++ difference. + + + +@@ -2967,44 +3434,6 @@ + + + &runtime; +- +- +- Generating and compiling External Core Files +- +- intermediate code generation +- +- GHC can dump its optimized intermediate code (said to be in “Core” format) +- to a file as a side-effect of compilation. Non-GHC back-end tools can read and process Core files; these files have the suffix +- .hcr. The Core format is described in +- An External Representation for the GHC Core Language, +- and sample tools +- for manipulating Core files (in Haskell) are available in the +- extcore package on Hackage. Note that the format of .hcr +- files is different from the Core output format that GHC generates +- for debugging purposes (), though the two formats appear somewhat similar. +- +- The Core format natively supports notes which you can add to +- your source code using the CORE pragma (see ). +- +- +- +- +- +- +- +- +- +- Generate .hcr files. +- +- +- +- +- +-Currently (as of version 6.8.2), GHC does not have the ability to read in External Core files as source. If you would like GHC to have this ability, please make your wishes known to the GHC Team. +- +- +- + &debug; + &flags; + +diff -urd 7.8.2-original/what_glasgow_exts_does.gen.xml original/what_glasgow_exts_does.gen.xml +--- 7.8.2-original/what_glasgow_exts_does.gen.xml 2014-06-27 09:59:33.000000000 +0900 ++++ original/what_glasgow_exts_does.gen.xml 2016-04-09 21:36:11.395998334 +0900 +@@ -1,31 +1,31 @@ +-, +-, +-, +-, +-, +-, +-, ++, + , +-, + , +-, ++, + , ++, ++, ++, ++, + , + , +-, +-, ++, + , ++, ++, ++, ++, + , +-, +-, +-, ++, ++, + , +-, ++, + , +-, +-, + , +-, +-, +-, +-. ++, ++, ++, ++, ++, ++, ++.