GitLab

Summary:
As proposed in [1], this extension introduces a new syntactic form
`static e`, where `e :: a` can be any closed expression. The static form
produces a value of type `StaticPtr a`, which works as a reference that
programs can "dereference" to get the value of `e` back. References are
like `Ptr`s, except that they are stable across invocations of a
program.

The relevant wiki pages are [2, 3], which describe the motivation/ideas
and implementation plan respectively.

[1] Jeff Epstein, Andrew P. Black, and Simon Peyton-Jones. Towards
Haskell in the cloud. SIGPLAN Not., 46(12):118–129, September 2011. ISSN
0362-1340.
[2] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers
[3] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers/ImplementationPlan

Authored-by: Facundo Domínguez <facundo.dominguez@tweag.io>
Authored-by: Mathieu Boespflug <m@tweag.io>
Authored-by: Alexander Vershilov <alexander.vershilov@tweag.io>

Test Plan: `./validate`

Reviewers: hvr, simonmar, simonpj, austin

Reviewed By: simonpj, austin

Subscribers: qnikst, bgamari, mboes, carter, thomie, goldfire

Differential Revision: https://phabricator.haskell.org/D550

GHC Trac Issues: #7015

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

Summary:
Previously 'ghc --show-options' showed all options that GHC can possibly
accept. With this patch, it'll only show the options that have effect in
non-interactive modes.
This change also adds support for using 'ghc --interactive --show-options'
which previously was disallowed. This command will show all options that have
effect in the interactive mode.
The CmdLineParser is updated to know about the GHC modes, and then each flag
is annotated with which mode it has effect.
This fixes #9259.

Test Plan:
Try out --show-options with --interactive on the command line. With and without
--interactive should give different results.
Run the test suite, mode001 has been updated to verify this new flag
combination.

Reviewers: austin, jstolarek

Reviewed By: austin, jstolarek

Subscribers: jstolarek, thomie, carter, simonmar

Differential Revision: https://phabricator.haskell.org/D337

GHC Trac Issues: #9259

Summary: (this has been submitted on behalf on @dreixel)

Reviewers: simonpj, hvr, austin

Reviewed By: simonpj, austin

Subscribers: goldfire, thomie, carter, dreixel

Differential Revision: https://phabricator.haskell.org/D476

GHC Trac Issues: #5462

In 1c0b5fdc (re #9224

) `BinaryLiterals`
was temporarily added to T4437's `expectedGhcOnlyExtensions` list. This
can now reverted as Cabal has been made aware of `BinaryLiterals`
(see haskell/cabal#1970 and haskell/cabal#1972).

updates Cabal submodule
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

Haskell2010 supports

- base-10 (prefix-less),
- base-8 (via `0[oO]`-prefix), and
- base-16 (via `0[xX]`-prefix) integer literals.

This commit adds syntax support for base-2 integer literals via the new `0[bB]`
prefix. The use of a `0b` prefix for indicating binary literals is known
from popular programming languages such as C++14, Perl, Python, Ruby, and Java.

This syntax extension is disabled by default and can be enabled via the
new `{-# LANGUAGE BinaryLiterals #-}` pragma and/or the new `-XBinaryLiterals`

This new extensions requires to upgrade the `ExtsBitmap` type from
`Word` to `Word64` as this adds a 33th flag which is not guaranteed to
fit into a `Word`.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

Differential Revision: https://phabricator.haskell.org/D22

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>

After some discussion on ghc-devs@ and elsewhere, it seemed favorable to
make this change as type holes don't let any invalid programs though,
they merely change what the compiler reports in case of certain errors
(namely unbound occurrences, or _ appearing on a LHS.)

Now, the warning mechanism is controlled by -f[no-]warn-type-errors,
just like any other regular warning. Again, on by default.

The documentation and tests have been updated accordingly.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Depends on [eb304bd9/ghc]

Signed-off-by: Austin Seipp <aseipp@pobox.com>

This patch makes the Data.Typeable.Typeable class work with arguments of any
kind. In particular, this removes the Typeable1..7 class hierarchy, greatly
simplyfing the whole Typeable story. Also added is the AutoDeriveTypeable
language extension, which will automatically derive Typeable for all types and
classes declared in that module. Since there is now no good reason to give
handwritten instances of the Typeable class, those are ignored (for backwards
compatibility), and a warning is emitted.

The old, kind-* Typeable class is now called OldTypeable, and lives in the
Data.OldTypeable module. It is deprecated, and should be removed in some future
version of GHC.

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

It now knows about all the differences between the extensions that
GHC knows, and the extensions that Cabal knows.