summaryrefslogtreecommitdiff
path: root/compiler/prelude/PrelInfo.lhs
Commit message (Collapse)AuthorAgeFilesLines
* compiler: de-lhs prelude/Austin Seipp2014-12-031-161/+0
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* prelude: detabify/unwhitespace PrelInfoAustin Seipp2014-07-201-35/+28
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* 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.
* Coercible is now exported from GHC.Types (#8894)Joachim Breitner2014-03-161-3/+1
| | | | | so do not export it in GHC.Prim, and also have the pseudo-code for GHC.Prim import GHC.Types, so that haddock is happy.
* Another reference to Note [Kind-changing of (~) and Coercible]Joachim Breitner2014-03-141-1/+4
|
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-1/+1
|
* Introduce coerce :: Coercible a b -> a -> bcoercibleJoachim Breitner2013-09-131-1/+1
| | | | | | | | | | | 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.
* Add support for evaluation of type-level natural numbers.Iavor S. Diatchki2013-09-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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`.
* Use -fwarn-tabs when validatingIan Lynagh2011-11-041-0/+7
| | | | | We only use it for "compiler" sources, i.e. not for libraries. Many modules have a -fno-warn-tabs kludge for now.
* Change the way IfExtName is serialized so (most) wired-in names get special ↵Max Bolingbroke2011-09-271-1/+1
| | | | | | | | 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.
* fix warningsSimon Marlow2011-09-211-1/+0
|
* move AvailInfo and related things into its own moduleSimon Marlow2011-09-211-14/+13
|
* Change the representation of export lists in .hi filesSimon Peyton Jones2011-08-021-12/+11
| | | | | | | | | | | | | | | | | | | | | | | Currently export list in .hi files are partitioned by module export M T(C1,C2) N f,g In each list we only have OccNames, all assumed to come from the parent module M or N resp. This patch changes the representatation so that export lists have full Names: export M.T(M.C1,M.C2), N.f, N.g Numerous advatages * AvailInfo no longer needs to be parameterised; it always contains Names * Fixes Trac #5306. This was the main provocation * Less to-and-fro conversion when reading interface files It's all generally simpler. Interface files should not get bigger, becuase they have a nice compact representation for Names.
* Added a VECTORISE pragmaManuel M T Chakravarty2011-02-201-11/+11
| | | | | | | | | | | | | | | - 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
* Move error-ids to MkCore (from PrelRules)simonpj@microsoft.com2010-09-141-2/+3
| | | | and adjust imports accordingly
* Remove GHC's haskell98 dependencyIan Lynagh2009-07-241-1/+1
|
* Fixes for haddock 0.8Ian Lynagh2008-07-211-1/+1
|
* PrelInfo is now warning-freeIan Lynagh2008-04-131-7/+2
|
* Fix CodingStyle#Warnings URLsIan Lynagh2007-09-041-1/+1
|
* Use OPTIONS rather than OPTIONS_GHC for pragmasIan Lynagh2007-09-031-2/+2
| | | | | | | Older GHCs can't parse OPTIONS_GHC. This also changes the URL referenced for the -w options from WorkingConventions#Warnings to CodingStyle#Warnings for the compiler modules.
* Add {-# OPTIONS_GHC -w #-} and some blurb to all compiler modulesIan Lynagh2007-09-011-0/+7
|
* Remove Linear Implicit Parameters, and all their workssimonpj@microsoft.com2006-09-291-1/+0
| | | | | | | Linear implicit parameters have been in GHC quite a while, but we decided they were a mis-feature and scheduled them for removal. This patch does the job.
* Massive patch for the first months work adding System FC to GHC #28Manuel M T Chakravarty2006-08-041-0/+3
| | | | | | | | Broken up massive patch -=chak Original log message: This is (sadly) all done in one patch to avoid Darcs bugs. It's not complete work... more FC stuff to come. A compiler using just this patch will fail dismally.
* Do not put wired-in things in interface filessimonpj@microsoft.com2006-05-081-2/+18
| | | | | | | | | | | | | | | There is no need for wired-in things to go into interface files; the compiler knows about them anyway. Worse, it turns ou that if they are in an interface file, they may get read in with not-quite-right type info (e.g. GHC.Err.error), and the not-quite-right thing gets into the type envt. Than it gets used instead of the wired in thing. Best all round never to put them into interface files. This is the way it used to be, but it looks as if it rotted away some time ago. (I noticed this when fixing unsafePerformIO stuff, becuase 'lazy' was getting an unfolding when it shouldn't.)
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+139
Most of the other users of the fptools build system have migrated to Cabal, and with the move to darcs we can now flatten the source tree without losing history, so here goes. The main change is that the ghc/ subdir is gone, and most of what it contained is now at the top level. The build system now makes no pretense at being multi-project, it is just the GHC build system. No doubt this will break many things, and there will be a period of instability while we fix the dependencies. A straightforward build should work, but I haven't yet fixed binary/source distributions. Changes to the Building Guide will follow, too.
View Lorry Controller Status