| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Integer is currently a wired-in type for integer-gmp. This requires
replicating its inner structure in `TysWiredIn`, which makes it much
harder to change Integer to a more complex representation (as
e.g. needed for implementing #9281)
This commit stops `Integer` being a wired-in type, and makes it
known-key type instead, thereby simplifying code notably.
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D351
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes Trac #8954.
There were actually three places where tuple occ-names
were parsed:
- IfaceEnv.lookupOrigNameCache
- Convert.isBuiltInOcc
- OccName.isTupleOcc_maybe
I combined all three into TysWiredIn.isBuiltInOcc_maybe
Much nicer.
|
| |
|
|
|
| |
This is done with two built-in type families: `CmpNat and `CmpSymbol`.
Both of these return a promoted `Ordering` type (EQ, LT, or GT).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
| |
This implements #8541. The changes are fully straight forward and work
nicely for the examples from the ticket; this is mostly due to the
existing code not checking for saturation and kindness.
|
| |
|
|
|
|
|
|
| |
wordTyCon was treated as wired-in, but
* It didn't have a WiredInName
* It didn't appear in the list of wiredInTyCons
I'm not sure how anything worked!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a `{-# MINIMAL #-}` pragma, which defines the possible
minimal complete definitions for a class. The body of the pragma is a
boolean formula of names.
The old warning for missing methods is replaced with this new one.
Note: The interface file format is changed to store the minimal complete
definition.
Authored-by: Twan van Laarhoven <twanvl@gmail.com>
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
This is the result of the design at
http://ghc.haskell.org/trac/ghc/wiki/NewtypeWrappers
The goal is to be able to convert between, say [First Int] and [Last
Int] with zero run-time overhead. To that end, we introduce a special
two parameter type class Coercible whose instances are created
automatically and on-the fly. This relies on and exploits the recent
addition of roles to core.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements some simple evaluation of type-level expressions
featuring natural numbers. We can evaluate *concrete* expressions that
use the built-in type families (+), (*), (^), and (<=?), declared in
GHC.TypeLits. We can also do some type inference involving these
functions. For example, if we encounter a constraint such as `(2 + x) ~ 5`
we can infer that `x` must be 3. Note, however, this is used only to
resolve unification variables (i.e., as a form of a constraint improvement)
and not to generate new facts. This is similar to how functional
dependencies work in GHC.
The patch adds a new form of coercion, `AxiomRuleCo`, which makes use
of a new form of axiom called `CoAxiomRule`. This is the form of evidence
generate when we solve a constraint, such as `(1 + 2) ~ 3`.
The patch also adds support for built-in type-families, by adding a new
form of TyCon rhs: `BuiltInSynFamTyCon`. such built-in type-family
constructors contain a record with functions that are used by the
constraint solver to simplify and improve constraints involving the
built-in function (see `TcInteract`). The record in defined in `FamInst`.
The type constructors and rules for evaluating the type-level functions
are in a new module called `TcTypeNats`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It should be the case that either an entire mutually recursive
group of data type declarations can be promoted, or none of them.
It's really odd to promote some data constructors of a type but
not others. Eg
data T a = T1 a | T2 Int
Here T1 is sort-of-promotable but T2 isn't (becuase Int isn't
promotable).
This patch makes it all-or-nothing. At the same time I've made
the TyCon point to its promoted cousin (via the tcPromoted field
of an AlgTyCon), as well as vice versa (via the ty_con field of
PromotedTyCon).
The inference for the group is done in TcTyDecls, the same place
that infers which data types are recursive, another global question.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes most of Trac #3990. Consider
data family D a
data instance D Double = CD Int Int
data T = T {-# UNPACK #-} !(D Double)
Then we want the (D Double unpacked).
To do this we need to construct a suitable coercion, and it's much
safer to record that coercion in the interface file, lest the in-scope
instances differ somehow. That in turn means elaborating the HsBang
type to include a coercion.
To do that I moved HsBang from BasicTypes to DataCon, which caused
quite a few minor knock-on changes.
Interface-file format has changed!
Still to do: need to do knot-tying to allow instances to take effect
within the same module.
|
| |
|
|
|
|
|
|
|
| |
They properly belong in TysWiredIn, since they are defined in Haskell
in GHC.TypeLits.
Moveover, make them WiredIn (again as they should be) and use
checkWiredInTyCon when encountering them in TcHsType.tc_hs_type,
so that the interface file is loaded. This fixes Trac #7502.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The situation was pretty dire. The way in which data constructors
were handled, notably the mapping between their *source* argument types
and their *representation* argument types (after seq'ing and unpacking)
was scattered in three different places, and hard to keep in sync.
Now it is all in one place:
* The dcRep field of a DataCon gives its representation,
specified by a DataConRep
* As well as having the wrapper, the DataConRep has a "boxer"
of type DataConBoxer (defined in MkId for loopy reasons).
The boxer used at a pattern match to reconstruct the source-level
arguments from the rep-level bindings in the pattern match.
* The unboxing in the wrapper and the boxing in the boxer are dual,
and are now constructed together, by MkId.mkDataConRep. This is
the key function of this change.
* All the computeBoxingStrategy code in TcTyClsDcls disappears.
Much nicer.
There is a little bit of refactoring left to do; the strange
deepSplitProductType functions are now called only in WwLib, so
I moved them there, and I think they could be tidied up further.
|
| |
|
|
|
|
|
|
| |
I don't konw how this was left out before; Trac #7347.
In fixing this I did the usual round of refactoring. In particular, I
cached the fact that a DataCon can be promoted in the DataCon
itself (the dcPromoted field).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch re-implements implicit parameters via a class
with a functional dependency:
class IP (n::Symbol) a | n -> a where
ip :: a
This definition is in the library module GHC.IP. Notice
how it use a type-literal, so we can have constraints like
IP "x" Int
Now all the functional dependency machinery works right to make
implicit parameters behave as they should.
Much special-case processing for implicit parameters can be removed
entirely. One particularly nice thing is not having a dedicated
"original-name cache" for implicit parameters (the nsNames field of
NameCache). But many other cases disappear:
* BasicTypes.IPName
* IPTyCon constructor in Tycon.TyCon
* CIPCan constructor in TcRnTypes.Ct
* IPPred constructor in Types.PredTree
Implicit parameters remain special in a few ways:
* Special syntax. Eg the constraint (IP "x" Int) is parsed
and printed as (?x::Int). And we still have local bindings
for implicit parameters, and occurrences thereof.
* A implicit-parameter binding (let ?x = True in e) amounts
to a local instance declaration, which we have not had before.
It just generates an implication contraint (easy), but when
going under it we must purge any existing bindings for
?x in the inert set. See Note [Shadowing of Implicit Parameters]
in TcSimplify
* TcMType.sizePred classifies implicit parameter constraints as size-0,
as before the change
There are accompanying patches to libraries 'base' and 'haddock'
All the work was done by Iavor Diatchki
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is done by a 'unarisation' pre-pass at the STG level which
translates away all (live) binders binding something of unboxed
tuple type.
This has the following knock-on effects:
* The subkind hierarchy is vastly simplified (no UbxTupleKind or ArgKind)
* Various relaxed type checks in typechecker, 'foreign import prim' etc
* All case binders may be live at the Core level
|
| | |
| |
| |
| |
| | |
By using Haskell's debugIsOn rather than CPP's "#ifdef DEBUG", we
don't need to kludge things to keep the warning checker happy etc.
|
| |/
|
|
| |
Haskell
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You can now say
data {-# CTYPE "some_header.h" "the C type" #-} Foo = ...
I think it's rare that this will actually be needed. If the
header for a CAPI FFI import includes a
void f(ctype x);
prototype then ctype must already be defined.
However, if the header only has
#define f(p) p->j
then the type need not be defined.
But either way, it seems good practice for us to specify the header that
we need.
|
| | |
|
| |
|
|
|
|
|
| |
For now, the syntax is
type {-# CTYPE "some C type" #-} Foo = ...
newtype {-# CTYPE "some C type" #-} Foo = ...
data {-# CTYPE "some C type" #-} Foo = ...
|
| |
|
|
| |
..and fix up Core Lint. (I was getting a bogus Core Lint failure.)
|
| |
|
|
| |
This fixes the ASSERT failure in Trac #5833 and type error in #5798
|
| |
|
|
|
|
|
|
|
| |
See Trac #5720: make the unit unboxed tuple (# #) behave uniformly
with the unit boxed tuple ()
This is actually a change in behaviour, but in a very dark corner,
so I don't think this is going to hurt anyone, and the current
behaviour is deeply strange.
|
| |
|
|
|
|
|
|
|
| |
This big patch implements a kind-polymorphic core for GHC. The current
implementation focuses on making sure that all kind-monomorphic programs still
work in the new core; it is not yet guaranteed that kind-polymorphic programs
(using the new -XPolyKinds flag) will work.
For more information, see http://haskell.org/haskellwiki/GHC/Kinds
|
| |
|
|
|
| |
We only use it for "compiler" sources, i.e. not for libraries.
Many modules have a -fno-warn-tabs kludge for now.
|
| |
|
|
|
|
|
|
| |
In particular we don't allow *nested* unboxed tuples, but the
typechecker wasn't actually enforcing that, which confused the
later stages of the compiler.
I also updated the documentation on unboxed tuples.
|
| |
|
|
|
|
|
|
| |
representation
This lets IfaceType be dumber, with fewer special cases, because deserialization for more
wired-in names will work. Once we have polymorphic kinds we will be able to replace IfaceTyCon
with a simple IfExtName.
|
| |
|
|
|
|
|
|
|
| |
LitInteger now carries around the id of mkInteger, which it uses
to construct the core to build Integer literals. This way we don't
have to build in info about lots of Ids.
We also no longer have any special-casing for integer-simple, so
there is less code involved.
|
| |
|
|
|
| |
In particular, use mkConApp when building the (S# i)
constructors in CorePrep
|
| |
|
|
|
|
| |
We now treat them as literals until CorePrep, when we finally
convert them into the real Core representation. This makes it a lot
simpler to implement built-in rules on them.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Basically as documented in http://hackage.haskell.org/trac/ghc/wiki/KindFact,
this patch adds a new kind Constraint such that:
Show :: * -> Constraint
(?x::Int) :: Constraint
(Int ~ a) :: Constraint
And you can write *any* type with kind Constraint to the left of (=>):
even if that type is a type synonym, type variable, indexed type or so on.
The following (somewhat related) changes are also made:
1. We now box equality evidence. This is required because we want
to give (Int ~ a) the *lifted* kind Constraint
2. For similar reasons, implicit parameters can now only be of
a lifted kind. (?x::Int#) => ty is now ruled out
3. Implicit parameter constraints are now allowed in superclasses
and instance contexts (this just falls out as OK with the new
constraint solver)
Internally the following major changes were made:
1. There is now no PredTy in the Type data type. Instead
GHC checks the kind of a type to figure out if it is a predicate
2. There is now no AClass TyThing: we represent classes as TyThings
just as a ATyCon (classes had TyCons anyway)
3. What used to be (~) is now pretty-printed as (~#). The box
constructor EqBox :: (a ~# b) -> (a ~ b)
4. The type LCoercion is used internally in the constraint solver
and type checker to represent coercions with free variables
of type (a ~ b) rather than (a ~# b)
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Resolved conflicts:
compiler/typecheck/TcTyClsDecls.lhs
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
See the paper "Practical aspects of evidence based compilation in System FC"
* Coercion becomes a data type, distinct from Type
* Coercions become value-level things, rather than type-level things,
(although the value is zero bits wide, like the State token)
A consequence is that a coerion abstraction increases the arity by 1
(just like a dictionary abstraction)
* There is a new constructor in CoreExpr, namely Coercion, to inject
coercions into terms
|
| |/
|
|
| |
handled, allow for standalone deriving of Representable0.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Added a pragma {-# VECTORISE var = exp #-} that prevents
the vectoriser from vectorising the definition of 'var'.
Instead it uses the binding '$v_var = exp' to vectorise
'var'. The vectoriser checks that the Core type of 'exp'
matches the vectorised Core type of 'var'. (It would be
quite complicated to perform that check in the type checker
as the vectorisation of a type needs the state of the VM
monad.)
- Added parts of a related VECTORISE SCALAR pragma
- Documented -ddump-vect
- Added -ddump-vt-trace
- Some clean up
|
| | |
|
