summaryrefslogtreecommitdiff
path: root/compiler/hsSyn/HsUtils.lhs
Commit message (Collapse)AuthorAgeFilesLines
* compiler: de-lhs hsSyn/Austin Seipp2014-12-031-906/+0
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Implement Partial Type SignaturesThomas Winant2014-11-281-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: Add support for Partial Type Signatures, i.e. holes in types, see: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures This requires an update to the Haddock submodule. Test Plan: validate Reviewers: austin, goldfire, simonpj Reviewed By: simonpj Subscribers: thomie, Iceland_jack, dominique.devriese, simonmar, carter, goldfire Differential Revision: https://phabricator.haskell.org/D168 GHC Trac Issues: #9478
* Rename some of the functions in NameSet, to make the uniform with VarSet etcSimon Peyton Jones2014-11-281-6/+6
| | | | | | | | | | | | | For ages NameSet has used different names, eg. addOneToNameSet rather than extendNameSet nameSetToList rather than nameSetElems etc. Other set-like modules use uniform naming conventions. This patch makes NameSet follow suit. No change in behaviour; this is just renaming. I'm doing this just before the fork so that merging is easier.
* Capture original source for literalsAlan Zimmerman2014-11-211-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Make HsLit and OverLitVal have original source strings, for source to source conversions using the GHC API This is part of the ongoing AST Annotations work, as captured in https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations and https://ghc.haskell.org/trac/ghc/ticket/9628#comment:28 The motivations for the literals is as follows ```lang=haskell x,y :: Int x = 0003 y = 0x04 s :: String s = "\x20" c :: Char c = '\x20' d :: Double d = 0.00 blah = x where charH = '\x41'# intH = 0004# wordH = 005## floatH = 3.20# doubleH = 04.16## x = 1 ``` Test Plan: ./sh validate Reviewers: simonpj, austin Reviewed By: simonpj, austin Subscribers: thomie, goldfire, carter, simonmar Differential Revision: https://phabricator.haskell.org/D412 GHC Trac Issues: #9628
* Add API AnnotationsAlan Zimmerman2014-11-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The final design and discussion is captured at https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations This is a proof of concept implementation of a completely separate annotation structure, populated in the parser,and tied to the AST by means of a virtual "node-key" comprising the surrounding SrcSpan and a value derived from the specific constructor used for the node. The key parts of the design are the following. == The Annotations == In `hsSyn/ApiAnnotation.hs` ```lang=haskell type ApiAnns = (Map.Map ApiAnnKey SrcSpan, Map.Map SrcSpan [Located Token]) type ApiAnnKey = (SrcSpan,AnnKeywordId) -- --------------------------------------------------------------------- -- | Retrieve an annotation based on the @SrcSpan@ of the annotated AST -- element, and the known type of the annotation. getAnnotation :: ApiAnns -> SrcSpan -> AnnKeywordId -> Maybe SrcSpan getAnnotation (anns,_) span ann = Map.lookup (span,ann) anns -- |Retrieve the comments allocated to the current @SrcSpan@ getAnnotationComments :: ApiAnns -> SrcSpan -> [Located Token] getAnnotationComments (_,anns) span = case Map.lookup span anns of Just cs -> cs Nothing -> [] -- | Note: in general the names of these are taken from the -- corresponding token, unless otherwise noted data AnnKeywordId = AnnAs | AnnBang | AnnClass | AnnClose -- ^ } or ] or ) or #) etc | AnnComma | AnnDarrow | AnnData | AnnDcolon .... ``` == Capturing in the lexer/parser == The annotations are captured in the lexer / parser by extending PState to include a field In `parser/Lexer.x` ```lang=haskell data PState = PState { .... annotations :: [(ApiAnnKey,SrcSpan)] -- Annotations giving the locations of 'noise' tokens in the -- source, so that users of the GHC API can do source to -- source conversions. } ``` The lexer exposes a helper function to add an annotation ```lang=haskell addAnnotation :: SrcSpan -> Ann -> SrcSpan -> P () addAnnotation l a v = P $ \s -> POk s { annotations = ((AK l a), v) : annotations s } () ``` The parser also has some helper functions of the form ```lang=haskell type MaybeAnn = Maybe (SrcSpan -> P ()) gl = getLoc gj x = Just (gl x) ams :: Located a -> [MaybeAnn] -> P (Located a) ams a@(L l _) bs = (mapM_ (\a -> a l) $ catMaybes bs) >> return a ``` This allows annotations to be captured in the parser by means of ``` ctypedoc :: { LHsType RdrName } : 'forall' tv_bndrs '.' ctypedoc {% hintExplicitForall (getLoc $1) >> ams (LL $ mkExplicitHsForAllTy $2 (noLoc []) $4) [mj AnnForall $1,mj AnnDot $3] } | context '=>' ctypedoc {% ams (LL $ mkQualifiedHsForAllTy $1 $3) [mj AnnDarrow $2] } | ipvar '::' type {% ams (LL (HsIParamTy (unLoc $1) $3)) [mj AnnDcolon $2] } | typedoc { $1 } ``` == Parse result == ```lang-haskell data HsParsedModule = HsParsedModule { hpm_module :: Located (HsModule RdrName), hpm_src_files :: [FilePath], -- ^ extra source files (e.g. from #includes). The lexer collects -- these from '# <file> <line>' pragmas, which the C preprocessor -- leaves behind. These files and their timestamps are stored in -- the .hi file, so that we can force recompilation if any of -- them change (#3589) hpm_annotations :: ApiAnns } -- | The result of successful parsing. data ParsedModule = ParsedModule { pm_mod_summary :: ModSummary , pm_parsed_source :: ParsedSource , pm_extra_src_files :: [FilePath] , pm_annotations :: ApiAnns } ``` This diff depends on D426 Test Plan: sh ./validate Reviewers: austin, simonpj, Mikolaj Reviewed By: simonpj, Mikolaj Subscribers: Mikolaj, goldfire, thomie, carter Differential Revision: https://phabricator.haskell.org/D438 GHC Trac Issues: #9628
* AST changes to prepare for API annotations, for #9628Alan Zimmerman2014-11-211-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: AST changes to prepare for API annotations Add locations to parts of the AST so that API annotations can then be added. The outline of the whole process is captured here https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations This change updates the haddock submodule. Test Plan: sh ./validate Reviewers: austin, simonpj, Mikolaj Reviewed By: simonpj, Mikolaj Subscribers: thomie, goldfire, carter Differential Revision: https://phabricator.haskell.org/D426 GHC Trac Issues: #9628
* nlHsTyApps: for applying a function both on type- and term-level argumentsDr. ERDI Gergo2014-11-131-1/+4
|
* A little refactoring of HsSplice and friendsSimon Peyton Jones2014-11-041-5/+3
| | | | | | | Plus adding comments. The most substantive change is that PendingTcSplice becomes a proper data type rather than a pair; and PendingRnSplice uses it
* remove old .NET related codeYuras Shumovich2014-10-311-1/+0
| | | | | | | | | | | | | | Summary: It seems to be dead anyway. Also update Haddock submodule. Test Plan: validate Reviewers: austin Reviewed By: austin Subscribers: thomie, goldfire, carter, simonmar Differential Revision: https://phabricator.haskell.org/D357
* Remove a few redundant `-fno-warn-tabs`sHerbert Valerio Riedel2014-09-251-6/+0
|
* Clean up Coercible handling, and interaction of data families with newtypesSimon Peyton Jones2014-09-191-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes Trac #9580, in which the Coercible machinery succeeded even though the relevant data constructor was not in scope. As usual I got dragged into a raft of refactoring changes, all for the better. * Delete TcEvidence.coercionToTcCoercion (now unused) * Move instNewTyConTF_maybe, instNewTyCon_maybe to FamInst, and rename them to tcInstNewTyConTF_maybe, tcInstNewTyCon (They both return TcCoercions.) * tcInstNewTyConTF_maybe also gets more convenient type, which improves TcInteract.getCoercibleInst * Define FamInst.tcLookupDataFamInst, and use it in TcDeriv, (as well as in tcInstNewTyConTF_maybe) * Improve error report for Coercible errors, when data familes are involved Another use of tcLookupDataFamInst * In TcExpr.tcTagToEnum, use tcLookupDataFamInst to replace local hacky code * Fix Coercion.instNewTyCon_maybe and Type.newTyConInstRhs to deal with eta-reduced newtypes, using (new) Type.unwrapNewTyConEtad_maybe and (new) Type.applyTysX Some small refactoring of TcSMonad.matchFam.
* PostTcType replaced with TypeAnnotAlan Zimmerman2014-09-061-129/+172
| | | | | | | | | | | | | | | | | | | | | Summary: This is a first step toward allowing generic traversals of the AST without 'landmines', by removing the `panic`s located throughout `placeHolderType`, `placeHolderKind` & co. See more on the discussion at https://www.mail-archive.com/ghc-devs@haskell.org/msg05564.html (This also makes a corresponding update to the `haddock` submodule.) Test Plan: `sh validate` and new tests pass. Reviewers: austin, simonpj, goldfire Reviewed By: austin, simonpj, goldfire Subscribers: edsko, Fuuzetsu, thomasw, holzensp, goldfire, simonmar, relrod, ezyang, carter Projects: #ghc Differential Revision: https://phabricator.haskell.org/D157
* Refactor PatSynBind so that we can pass around PSBs instead of several argumentsDr. ERDI Gergo2014-07-291-6/+8
|
* Fixed issue with detection of duplicate record fieldsGintautas Miliauskas2014-07-241-12/+19
| | | | | | | | | Duplicate record fields would not be detected when given a type with multiple data constructors, and the first data constructor had a record field r1 and any consecutive data constructors had multiple fields named r1. This fixes #9156 and was reviewed in https://phabricator.haskell.org/D87
* Remove dead code. Fix comment typo.Jan Stolarek2014-06-301-1/+1
|
* Fix egregious instantiation bug in matchOneConLike (fixing Trac #9023)Simon Peyton Jones2014-06-051-1/+1
| | | | | | | | | | | | | | | We simply weren't giving anything like the right instantiating types to patSynInstArgTys in matchOneConLike. To get these instantiating types would have involved matching the result type of the pattern synonym with the pattern type, which is tiresome. So instead I changed ConPatOut so that instead of recording the type of the *whole* pattern (in old field pat_ty), it not records the *instantiating* types (in new field pat_arg_tys). Then we canuse TcHsSyn.conLikeResTy to get the pattern type when needed. There are lots of knock-on incidental effects, but they mostly made the code simpler, so I'm happy.
* Add LANGUAGE pragmas to compiler/ source filesHerbert Valerio Riedel2014-05-151-1/+2
| | | | | | | | | | | | | | | | | | In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been reorganized, while following the convention, to - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before any `{-# OPTIONS_GHC #-}`-lines. - Moreover, if the list of language extensions fit into a single `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each individual language extension. In both cases, try to keep the enumeration alphabetically ordered. (The latter layout is preferable as it's more diff-friendly) While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
* Instead of tracking Origin in LHsBindsLR, track it in MatchGroupDr. ERDI Gergo2014-04-131-23/+23
|
* Squash some spelling issuesGabor Greif2014-01-261-1/+1
|
* Implement pattern synonymsDr. ERDI Gergo2014-01-201-10/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements Pattern Synonyms (enabled by -XPatternSynonyms), allowing y ou to assign names to a pattern and abstract over it. The rundown is this: * Named patterns are introduced by the new 'pattern' keyword, and can be either *unidirectional* or *bidirectional*. A unidirectional pattern is, in the simplest sense, simply an 'alias' for a pattern, where the LHS may mention variables to occur in the RHS. A bidirectional pattern synonym occurs when a pattern may also be used in expression context. * Unidirectional patterns are declared like thus: pattern P x <- x:_ The synonym 'P' may only occur in a pattern context: foo :: [Int] -> Maybe Int foo (P x) = Just x foo _ = Nothing * Bidirectional patterns are declared like thus: pattern P x y = [x, y] Here, P may not only occur as a pattern, but also as an expression when given values for 'x' and 'y', i.e. bar :: Int -> [Int] bar x = P x 10 * Patterns can't yet have their own type signatures; signatures are inferred. * Pattern synonyms may not be recursive, c.f. type synonyms. * Pattern synonyms are also exported/imported using the 'pattern' keyword in an import/export decl, i.e. module Foo (pattern Bar) where ... Note that pattern synonyms share the namespace of constructors, so this disambiguation is required as a there may also be a 'Bar' type in scope as well as the 'Bar' pattern. * The semantics of a pattern synonym differ slightly from a typical pattern: when using a synonym, the pattern itself is matched, followed by all the arguments. This means that the strictness differs slightly: pattern P x y <- [x, y] f (P True True) = True f _ = False g [True, True] = True g _ = False In the example, while `g (False:undefined)` evaluates to False, `f (False:undefined)` results in undefined as both `x` and `y` arguments are matched to `True`. For more information, see the wiki: https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation Reviewed-by: Simon Peyton Jones <simonpj@microsoft.com> Signed-off-by: Austin Seipp <austin@well-typed.com>
* Comments onlySimon Peyton Jones2013-12-301-3/+6
|
* Fix #8607.Richard Eisenberg2013-12-261-24/+28
| | | | | | | | | | | The solution (after many false starts) is to change the behavior of hsLTyClDeclBinders. The idea is that the locations of the names that the parser generates should really be the names' locations, unlike what was done in 1745779... But, when the renamer is creating Names from the RdrNames, the locations stored in the Names should be the declarations' locations. This is now achieved in hsLTyClDeclBinders, which returns [Located name], but the location is that of the *declaration*, not the name itself.
* Comments onlySimon Peyton Jones2013-11-281-1/+4
|
* Roleify TcCoercionJoachim Breitner2013-11-271-6/+4
| | | | | | | | | | | | Previously, TcCoercion were only used to represent boxed Nominal coercions. In order to also talk about boxed Representational coercions in the type checker, we add Roles to TcCoercion. Again, we closely mirror Coercion. The roles are verified by a few assertions, and at the latest after conversion to Coercion. I have put my trust in the comprehensiveness of the testsuite here, but any role error after desugaring popping up now might be caused by this refactoring.
* In toHsType, filter out kind variablesJoachim Breitner2013-11-251-1/+2
| | | | (This fixes #8563)
* Another raft of Template Haskell clean-upSimon Peyton Jones2013-11-251-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The handling of typed and untyped brackets was extremely convoluted, partly because of the evolutionary history. I've tidied it all up. See Note [How brackets and nested splices are handled] in TcSplice for the full story Main changes: * Untyped brackets: after the renamer, HsRnBracketOut carries PendingRnSplices for splices in untyped brackets. In the typechecker, these pending splices are typechecked quite straigtforwardly, with no ps_var nonsense. * Typed brackets: after the renamer typed brackest still look like HsBracket. The type checker does the ps_var thing. * In TcRnTypes.ThStage, the Brack constructor, we distinguish the renaming from typehecking pending-stuff. Much more perspicuous! * The "typed" flag is in HsSpliceE, not in HsSplice, because only expressions can be typed. Patterns, types, declarations cannot. There is further improvement to be done to make the handling of declaration splices more uniform.
* Implement GeneralizedNewtypeDeriving in terms of `coerce`.Richard Eisenberg2013-11-221-1/+47
|
* Add support for pattern splices.Geoffrey Mainland2013-10-041-0/+1
|
* Clean up smart constructors for splices.Geoffrey Mainland2013-10-041-6/+9
|
* Differentiate typed and untyped splices and brackets in the abstract syntax.Geoffrey Mainland2013-10-041-2/+5
|
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-1/+1
|
* Change role annotation syntax.Richard Eisenberg2013-09-171-3/+3
| | | | | | | | | This fixes bugs #8185, #8234, and #8246. The new syntax is explained in the comments to #8185, appears in the "Roles" subsection of the manual, and on the [wiki:Roles] wiki page. This change also removes the ability for a role annotation on type synonyms, as noted in #8234.
* Implement "roles" into GHC.Richard Eisenberg2013-08-021-1/+1
| | | | | | | | | | | | | | | | Roles are a solution to the GeneralizedNewtypeDeriving type-safety problem. Roles were first described in the "Generative type abstraction" paper, by Stephanie Weirich, Dimitrios Vytiniotis, Simon PJ, and Steve Zdancewic. The implementation is a little different than that paper. For a quick primer, check out Note [Roles] in Coercion. Also see http://ghc.haskell.org/trac/ghc/wiki/Roles and http://ghc.haskell.org/trac/ghc/wiki/RolesImplementation For a more formal treatment, check out docs/core-spec/core-spec.pdf. This fixes Trac #1496, #4846, #7148.
* Rearrange the typechecking of arrows, especially arrow "forms"Simon Peyton Jones2013-03-041-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The typechecking of arrow forms (in GHC 7.6) is known to be bogus, as described in Trac #5609, because it marches down tuple types that may not yet be fully worked out, depending on when constraint solving happens. Moreover, coercions are generated and simply discarded. The fact that it works at all is a miracle. This refactoring is based on a conversation with Ross, where we rearranged the typing of the argument stack, so that the arrows have the form a (env, (arg1, (arg2, ...(argn, ())))) res rather than a (arg1, (arg2, ...(argn, env))) res as it was before. This is vastly simpler to typecheck; just look at the beautiful, simple type checking of arrow forms now! We need a new HsCmdCast to capture the coercions generated from the argument stack. This leaves us in a better position to tackle the open arrow tickets * Trac #5777 still fails. (I was hoping this patch would cure it.) * Trac #5609 is too complicated for me to grok. Ross? * Trac #344 * Trac #5333
* Add OverloadedLists, allowing list syntax to be overloadedSimon Peyton Jones2013-02-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | This work was all done by Achim Krause <achim.t.krause@gmail.com> George Giorgidze <giorgidze@gmail.com> Weijers Jeroen <jeroen.weijers@uni-tuebingen.de> It allows list syntax, such as [a,b], [a..b] and so on, to be overloaded so that it works for a variety of types. The design is described here: http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists Eg. you can use it for maps, so that [(1,"foo"), (4,"bar")] :: Map Int String The main changes * The ExplicitList constructor of HsExpr gets witness field * Ditto ArithSeq constructor * Ditto the ListPat constructor of HsPat Everything else flows from this.
* Refactor HsExpr.MatchGroupSimon Peyton Jones2013-01-041-1/+1
| | | | | | | | | | | * Make MatchGroup into a record, and use the record fields * Split the type field into two: mg_arg_tys and mg_res_ty This makes life much easier for the desugarer when the case alterantives are empty A little bit of this change unavoidably ended up in the preceding commit about empty case alternatives
* Implement overlapping type family instances.Richard Eisenberg2012-12-211-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An ordered, overlapping type family instance is introduced by 'type instance where', followed by equations. See the new section in the user manual (7.7.2.2) for details. The canonical example is Boolean equality at the type level: type family Equals (a :: k) (b :: k) :: Bool type instance where Equals a a = True Equals a b = False A branched family instance, such as this one, checks its equations in order and applies only the first the matches. As explained in the note [Instance checking within groups] in FamInstEnv.lhs, we must be careful not to simplify, say, (Equals Int b) to False, because b might later unify with Int. This commit includes all of the commits on the overlapping-tyfams branch. SPJ requested that I combine all my commits over the past several months into one monolithic commit. The following GHC repos are affected: ghc, testsuite, utils/haddock, libraries/template-haskell, and libraries/dph. Here are some details for the interested: - The definition of CoAxiom has been moved from TyCon.lhs to a new file CoAxiom.lhs. I made this decision because of the number of definitions necessary to support BranchList. - BranchList is a GADT whose type tracks whether it is a singleton list or not-necessarily-a-singleton-list. The reason I introduced this type is to increase static checking of places where GHC code assumes that a FamInst or CoAxiom is indeed a singleton. This assumption takes place roughly 10 times throughout the code. I was worried that a future change to GHC would invalidate the assumption, and GHC might subtly fail to do the right thing. By explicitly labeling CoAxioms and FamInsts as being Unbranched (singleton) or Branched (not-necessarily-singleton), we make this assumption explicit and checkable. Furthermore, to enforce the accuracy of this label, the list of branches of a CoAxiom or FamInst is stored using a BranchList, whose constructors constrain its type index appropriately. I think that the decision to use BranchList is probably the most controversial decision I made from a code design point of view. Although I provide conversions to/from ordinary lists, it is more efficient to use the brList... functions provided in CoAxiom than always to convert. The use of these functions does not wander far from the core CoAxiom/FamInst logic. BranchLists are motivated and explained in the note [Branched axioms] in CoAxiom.lhs. - The CoAxiom type has changed significantly. You can see the new type in CoAxiom.lhs. It uses a CoAxBranch type to track branches of the CoAxiom. Correspondingly various functions producing and consuming CoAxioms had to change, including the binary layout of interface files. - To get branched axioms to work correctly, it is important to have a notion of type "apartness": two types are apart if they cannot unify, and no substitution of variables can ever get them to unify, even after type family simplification. (This is different than the normal failure to unify because of the type family bit.) This notion in encoded in tcApartTys, in Unify.lhs. Because apartness is finer-grained than unification, the tcUnifyTys now calls tcApartTys. - CoreLinting axioms has been updated, both to reflect the new form of CoAxiom and to enforce the apartness rules of branch application. The formalization of the new rules is in docs/core-spec/core-spec.pdf. - The FamInst type (in types/FamInstEnv.lhs) has changed significantly, paralleling the changes to CoAxiom. Of course, this forced minor changes in many files. - There are several new Notes in FamInstEnv.lhs, including one discussing confluent overlap and why we're not doing it. - lookupFamInstEnv, lookupFamInstEnvConflicts, and lookup_fam_inst_env' (the function that actually does the work) have all been more-or-less completely rewritten. There is a Note [lookup_fam_inst_env' implementation] describing the implementation. One of the changes that affects other files is to change the type of matches from a pair of (FamInst, [Type]) to a new datatype (which now includes the index of the matching branch). This seemed a better design. - The TySynInstD constructor in Template Haskell was updated to use the new datatype TySynEqn. I also bumped the TH version number, requiring changes to DPH cabal files. (That's why the DPH repo has an overlapping-tyfams branch.) - As SPJ requested, I refactored some of the code in HsDecls: * splitting up TyDecl into SynDecl and DataDecl, correspondingly changing HsTyDefn to HsDataDefn (with only one constructor) * splitting FamInstD into TyFamInstD and DataFamInstD and splitting FamInstDecl into DataFamInstDecl and TyFamInstDecl * making the ClsInstD take a ClsInstDecl, for parallelism with InstDecl's other constructors * changing constructor TyFamily into FamDecl * creating a FamilyDecl type that stores the details for a family declaration; this is useful because FamilyDecls can appear in classes but other decls cannot * restricting the associated types and associated type defaults for a * class to be the new, more restrictive types * splitting cid_fam_insts into cid_tyfam_insts and cid_datafam_insts, according to the new types * perhaps one or two more that I'm overlooking None of these changes has far-reaching implications. - The user manual, section 7.7.2.2, is updated to describe the new type family instances.
* This big patch re-factors the way in which arrow-syntax is handledSimon Peyton Jones2012-10-031-36/+40
| | | | | | | | | | | | | | | | | | | | | | All the work was done by Dan Winograd-Cort. The main thing is that arrow comamnds now have their own data type HsCmd (defined in HsExpr). Previously it was punned with the HsExpr type, which was jolly confusing, and made it hard to do anything arrow-specific. To make this work, we now parameterise * MatchGroup * Match * GRHSs, GRHS * StmtLR and friends over the "body", that is the kind of thing they enclose. This "body" parameter can be instantiated to either LHsExpr or LHsCmd respectively. Everything else is really a knock-on effect; there should be no change (yet!) in behaviour. But it should be a sounder basis for fixing bugs.
* Refactor LHsTyVarBndrs to fix Trac #6081Simon Peyton Jones2012-05-111-4/+1
| | | | | | | | | | | | | | | This is really a small change, but it touches a lot of files quite significantly. The real goal is to put the implicitly-bound kind variables of a data/class decl in the right place, namely on the LHsTyVarBndrs type, which now looks like data LHsTyVarBndrs name = HsQTvs { hsq_kvs :: [Name] , hsq_tvs :: [LHsTyVarBndr name] } This little change made the type checker neater in a number of ways, but it was fiddly to push through the changes.
* Tidy up a remaining glitch in unificationSimon Peyton Jones2012-05-011-6/+6
| | | | | | | | | | | | | | | | | | There was one place, in type checking parallel list comprehensions where we were unifying types, but had no convenient way to use the resulting coercion; instead we just checked that it was Refl. This was Wrong Wrong; it might fail unpredicably in a GADT-like situation, and it led to extra error-generation code used only in this one place. This patch tidies it all up, by moving the 'return' method from the *comprehension* to the ParStmtBlock. The latter is a new data type, now used for each sub-chunk of a parallel list comprehension. Because of the data type change, quite a few modules are touched, but only in a fairly trivial way. The real changes are in TcMatches (and corresponding desugaring); plus deleting code from TcUnify. This patch also fixes the pretty-printing bug in Trac #6060
* Do SCC on instance declarations (fixes Trac #5715)Simon Peyton Jones2012-04-201-1/+1
| | | | | | | | | | | | | | | | | | The trouble here is that given {-# LANGUAGE DataKinds, TypeFamilies #-} data instance Foo a = Bar (Bar a) we want to get a sensible message that we can't use the promoted 'Bar' constructor until after its definition; it's a staging error. Bud the staging mechanism that we use for vanilla data declarations don't work here. Solution is to perform strongly-connected component analysis on the instance declarations. But that in turn means that we need to track free-variable information on more HsSyn declarations, which is why so many files are touched. All the changes are boiler-platey except the ones in TcInstDcls.
* Allow kind-variable binders in type signaturesSimon Peyton Jones2012-04-131-33/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the last major addition to the kind-polymorphism story, by allowing (Trac #5938) type family F a -- F :: forall k. k -> * data T a -- T :: forall k. k -> * type instance F (T (a :: Maybe k)) = Char The new thing is the explicit 'k' in the type signature on 'a', which itself is inside a type pattern for F. Main changes are: * HsTypes.HsBSig now has a *pair* (kvs, tvs) of binders, the kind variables and the type variables * extractHsTyRdrTyVars returns a pair (kvs, tvs) and the function itself has moved from RdrHsSyn to RnTypes * Quite a bit of fiddling with TcHsType.tcHsPatSigType and tcPatSig which have become a bit simpler. I'm still not satisfied though. There's some consequential fiddling in TcRules too. * Removed the unused HsUtils.collectSigTysFromPats There's a consequential wibble to Haddock too
* Make the 'extract' functions to find free type variablesSimon Peyton Jones2012-03-261-2/+2
| | | | | | | of an HsType return RdrNames rather than (Located RdrNames). This means less clutter, and the individual locations are a bit arbitrary if a name occurs more than once.
* Merge branch 'master' of http://darcs.haskell.org//ghcSimon Peyton Jones2012-03-241-2/+3
|\ | | | | | | | | Conflicts: compiler/main/HscStats.lhs
| * Deal with kind variables brought into scope by a kind signatureSimon Peyton Jones2012-03-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This fixes Trac #5937, where a kind variable is mentioned only in the kind signature of a GADT data SMaybe :: (k -> *) -> Maybe k -> * where ... The main change is that the tcdKindSig field of TyData and TyFamily now has type Maybe (HsBndrSig (LHsKind name)), where the HsBndrSig part deals with the kind variables that the signature may bind. I also removed the now-unused PostTcKind field of UserTyVar and KindedTyVar.
* | Refactor HsDecls.TyClDecl to extract the type HsTyDefn, which is theSimon Peyton Jones2012-03-221-16/+32
| | | | | | | | | | RHS of a data type or type synonym declaration. This can be shared between type declarations and type *instance* declarations.
* | Deal with kind variables brought into scope by a kind signatureSimon Peyton Jones2012-03-141-1/+1
|/ | | | | | | | | | | | | This fixes Trac #5937, where a kind variable is mentioned only in the kind signature of a GADT data SMaybe :: (k -> *) -> Maybe k -> * where ... The main change is that the tcdKindSig field of TyData and TyFamily now has type Maybe (HsBndrSig (LHsKind name)), where the HsBndrSig part deals with the kind variables that the signature may bind. I also removed the now-unused PostTcKind field of UserTyVar and KindedTyVar.
* Hurrah! This major commit adds support for scoped kind variables,Simon Peyton Jones2012-03-021-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | which (finally) fills out the functionality of polymorphic kinds. It also fixes numerous bugs. Main changes are: Renaming stuff ~~~~~~~~~~~~~~ * New type in HsTypes: data HsBndrSig sig = HsBSig sig [Name] which is used for type signatures in patterns, and kind signatures in types. So when you say f (x :: [a]) = x ++ x or data T (f :: k -> *) (x :: *) = MkT (f x) the signatures in both cases are a HsBndrSig. * The [Name] in HsBndrSig records the variables bound by the pattern, that is 'a' in the first example, 'k' in the second, and nothing in the third. The renamer initialises the field. * As a result I was able to get rid of RnHsSyn.extractHsTyNames :: LHsType Name -> NameSet and its friends altogether. Deleted the entire module! This led to some knock-on refactoring; in particular the type renamer now returns the free variables just like the term renamer. Kind-checking types: mainly TcHsType ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A major change is that instead of kind-checking types in two passes, we now do one. Under the old scheme, the first pass did kind-checking and (hackily) annotated the HsType with the inferred kinds; and the second pass desugared the HsType to a Type. But now that we have kind variables inside types, the first pass (TcHsType.tc_hs_type) can go straight to Type, and zonking will squeeze out any kind unification variables later. This is much nicer, but it was much more fiddly than I had expected. The nastiest corner is this: it's very important that tc_hs_type uses lazy constructors to build the returned type. See Note [Zonking inside the knot] in TcHsType. Type-checking type and class declarations: mainly TcTyClsDecls ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I did tons of refactoring in TcTyClsDecls. Simpler and nicer now. Typechecking bindings: mainly TcBinds ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I rejigged (yet again) the handling of type signatures in TcBinds. It's a bit simpler now. The main change is that tcTySigs goes right through to a TcSigInfo in one step; previously it was split into two, part here and part later. Unsafe coercions ~~~~~~~~~~~~~~~~ Usually equality coercions have exactly the same kind on both sides. But we do allow an *unsafe* coercion between Int# and Bool, say, used in case error Bool "flah" of { True -> 3#; False -> 0# } --> (error Bool "flah") |> unsafeCoerce Bool Int# So what is the instantiation of (~#) here? unsafeCoerce Bool Int# :: (~#) ??? Bool Int# I'm using OpenKind here for now, but it's un-satisfying that the lhs and rhs of the ~ don't have precisely the same kind. More minor ~~~~~~~~~~ * HsDecl.TySynonym has its free variables attached, which makes the cycle computation in TcTyDecls.mkSynEdges easier. * Fixed a nasty reversed-comparison bug in FamInstEnv: @@ -490,7 +490,7 @@ lookup_fam_inst_env' match_fun one_sided ie fam tys n_tys = length tys extra_tys = drop arity tys (match_tys, add_extra_tys) - | arity > n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys) + | arity < n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys) | otherwise = (tys, \res_tys -> res_tys)
* Refactor HsDecls again, to put family instances in InstDeclSimon Peyton Jones2012-02-061-10/+14
| | | | | | | | | | | | | | | | | | | | This continues the clean up of the front end. Since they were first invented, type and data family *instance* decls have been in the TyClDecl data type, even though they always treated separately. This patch takes a step in the right direction * The InstDecl type now includes both class instances and type/data family instances * The hs_tyclds field of HsGroup now never has any family instance declarations in it However a family instance is still a TyClDecl. It should really be a separate type, but that's the next step. All this was provoked by fixing Trac #5792 in the HEAD. (I did a less invasive fix on the branch.)
* fix #5022: polymorphic definitions inside arrow recRoss Paterson2011-12-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | This is quite tricky, with examples like this: import Control.Arrow pRepeat :: a -> [a] pRepeat = proc x -> do rec s <- returnA -< f_rec x:s -- f_rec is monomorphic here let f_later y = y -- f_later is polymorphic here _ <- returnA -< (f_later True, f_later 'a') let f_rec y = y -- f_rec is polymorphic here returnA -< f_later s -- f_later is monomorphic here Fixed the typechecking of arrow RecStmt to track changes to the monad version. It was simplest to add a field recS_later_rets corresponding to recS_rec_rets. It's only used for the arrow version, and always empty for the monad version. But I think it would be cleaner to put the rec_ids and later_ids in a single list with supplementary info saying how they're used. Also fixed several glitches in the desugaring of arrow RecStmt. The fact that the monomorphic variables shadow their polymorphic counterparts is a major pain. Also a bit of general cleanup of DsArrows while I was there.
View Lorry Controller Status