GitLab

I did some refactoring of the demand analyser, because I was smelling
some minor code smell. Most of my changes I had to undo, though,
adding notes and testcases on why the existing code was correct after
all.

Especially the semantics of the DmdResult is confusing, as it differs in
a DmdType and a StrictSig.

I got to imrpove the readability of the code for lubDmdType, though.

Also, dmdAnalRhs was a bit fishy in how it removed the demand on
further arguments of the body, but used the DmdResult. This would be
wrong if a body would return a demand type of "<L>m" (which currently
does not happen).  This is now treated better in removeDmdTyArgs.

catching mistakes that I had during my refactoring, and which I do not
want to do again.

Signed-off-by: Austin Seipp <austin@well-typed.com>

My build settings were wrong last time.
Signed-off-by: Austin Seipp <austin@well-typed.com>

This reverts commit c5088e29.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Some of these are actually worse than I thought upon inspection, but
after a little digging I haven't found exactly what has caused them.
Some were certainly bitrotted, but others seem updated more recently, so
something has slipped.

I'll be filing a ticket about these.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

In particular, spell out the current dynamic situation, clean up the
FIXMEs and xrefs, and don't forget to mention InterruptibleFFI.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Rather hilarious (and my fault.)
Signed-off-by: Austin Seipp <austin@well-typed.com>

A few appear to have bitrotted a little. There are others we are
actually doing better on, but that will come in the next commit.
Signed-off-by: Austin Seipp <austin@well-typed.com>

When using TemplateHaskell and -prof, we *do not* want -dynamic-too, because
we're going to *expect* that you compiled the vanilla/dyn way already,
and are compiling profiling the second time (i.e. so GHCi can just load
the normal, non-profiled object files.)
Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

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/ImplementationReviewed-by: Simon Peyton Jones <simonpj@microsoft.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

(artificial test cases are so nice: 90.7% improvement!)

by passing the FamInstEnvs all the way down. This closes #7619.

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

On FreeBSD, /usr/lib has to be added to the library path on linking when
libthr is needed but -nostdlib is used (which is the case when the -prof
and -threaded flags are combined).

All actively supported releases (8.4-RELEASE, 9.2-RELEASE and the
upcoming 10.0-RELEASE) now support resolution of $ORIGIN properly.

Haddock no longer has a generated parser, so we don't need it in the
sdist and we certainly don't want to check for it in the ./configure
script (as that would be bogus.)
Signed-off-by: Austin Seipp <austin@well-typed.com>

See Trac #8672

Fixes Trac #8674

The former adds a newline at the end (restoring the previous behaviour)
while the latter does not (which previously happened by turning the
thuing into a string and only then printing it).