GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-05-07T13:22:23Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/20565stimes for Endo2022-05-07T13:22:23ZDavid Feuerstimes for Endo## Summary
Currently,
```haskell
instance Semigroup (Endo a) where
...
stimes = stimesMonoid
```
`stimesMonoid` produces a balanced tree. I guess this enhances sharing within the resulting function (if it's realized as a closu...## Summary
Currently,
```haskell
instance Semigroup (Endo a) where
...
stimes = stimesMonoid
```
`stimesMonoid` produces a balanced tree. I guess this enhances sharing within the resulting function (if it's realized as a closure), but I'm wondering if it's really a good idea, especially when the argument is small.
Here's a simpler option to play with:
```haskell
stimes n _ | n < 0 = error "Cannot apply a function a negative number of times."
stimes n0 e = go (fromIntegral n0)
where
go 0 = mempty
go n = e <> go (n - 1 :: Word64)
```
Another possibility might be to make a tree that only *leans* to the right. That would get immediate access to the leftmost (most important) nodes while maintaining sharing for the large case.
## Environment
* GHC version used:
Optional:
* Operating System:
* System Architecture:⊥https://gitlab.haskell.org/ghc/ghc/-/issues/20420Alternative "field-like" superclass syntax2021-12-23T12:53:28ZJohn EricsonAlternative "field-like" superclass syntaxThis idea swirls around my head from time to time, so I figured I would write it down.
## Motivation
The current superclass notation, piggy-backing on the notation instance constraints, is misleading. The issue is that instance constra...This idea swirls around my head from time to time, so I figured I would write it down.
## Motivation
The current superclass notation, piggy-backing on the notation instance constraints, is misleading. The issue is that instance constraints really are inputs, but superclass constraints are actually *outputs* when using the class, and just inputs when building an instance for it.
Or, since we are talking about constraint types themselves, not their (canonical) inhabitants, super classes are things you project, not domains of some sort of function type.
Worse, with Dependent Haskell, we could well need constraints in the *Kind* of the class, e.g. if a ("promoted") class member is then used in the rest of the kind (dependent constraint). Those goes backs to the debates on "constrained type families", "dataype contexts", and other things I should link (TODO) but would be tedious to rehash.
## Proposal
```haskell
class Foo a where
instance Bar a
```
instead of
```haskell
class Bar a => Foo a where
```⊥John EricsonJohn Ericsonhttps://gitlab.haskell.org/ghc/ghc/-/issues/20347Missed Optimization in numeric code2022-02-17T15:22:47ZNeoMissed Optimization in numeric codeIn functions like the once below the two negation operations can be safely eliminated. The optimization is valid for all integer and floating point types. The same story is of course true for division.
```
f_int_1 :: Int -> Int -> Int...In functions like the once below the two negation operations can be safely eliminated. The optimization is valid for all integer and floating point types. The same story is of course true for division.
```
f_int_1 :: Int -> Int -> Int
f_int_1 x y = (- x) * (-y)
f_double_1 :: Double -> Double -> Double
f_double_1 x y = (- x) * (- y)
```
Right now we produce:
```
f_int_1
= \ (x_a2tn :: Int) (y_a2to :: Int) ->
case x_a2tn of { GHC.Types.I# x1_i2ve ->
case y_a2to of { GHC.Types.I# x2_X2vE ->
GHC.Types.I#
(GHC.Prim.*#
(GHC.Prim.negateInt# x1_i2ve) (GHC.Prim.negateInt# x2_X2vE))
}
}
f_double_1
= \ (x_a2tq :: Double) (y_a2tr :: Double) ->
case x_a2tq of { GHC.Types.D# x1_a2vt ->
case y_a2tr of { GHC.Types.D# x2_X2vV ->
GHC.Types.D#
(GHC.Prim.*##
(GHC.Prim.negateDouble# x1_a2vt) (GHC.Prim.negateDouble# x2_X2vV))
}
}
```
Moreover for the following two functions we could be (at compile time) removing the negation from the variable and pushing it into the constant:
```
f_int_2 :: Int -> Int
f_int_2 x = 3 * (-x)
f_double_2 :: Double -> Double
f_double_2 x = 3.0 * (-x)
```
we should be transforming these into:
```
f_int_2 :: Int -> Int
f_int_2 x = -3 * x
f_double_2 :: Double -> Double
f_double_2 x = -3.0 * x
```⊥Sylvain HenrySylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/20324Potential bug in `zapFragileUnfolding`2021-09-23T14:53:49ZAndreas KlebingerPotential bug in `zapFragileUnfolding`Currently it's defined like this:
```haskell
zapFragileUnfolding :: Unfolding -> Unfolding
-- ^ Zaps any core unfolding, but /preserves/ evaluated-ness,
-- i.e. an unfolding of OtherCon
zapFragileUnfolding unf
| hasCoreUnfolding unf = ...Currently it's defined like this:
```haskell
zapFragileUnfolding :: Unfolding -> Unfolding
-- ^ Zaps any core unfolding, but /preserves/ evaluated-ness,
-- i.e. an unfolding of OtherCon
zapFragileUnfolding unf
| hasCoreUnfolding unf = noUnfolding
| otherwise = unf
```
But that's a bit odd. Clearly if the unfolding is something like `Just 1 :: Maybe Int` that's evaluated *and* a core unfolding. But we will lose the evaluatedness of this unfolding in the current implementation!
Rather it should probably be:
```haskell
zapFragileUnfolding :: Unfolding -> Unfolding
-- ^ Zaps any core unfolding, but /preserves/ evaluated-ness,
-- i.e. an unfolding of OtherCon
zapFragileUnfolding unf
| isEvaldUnfolding unf = evaldUnfolding
| otherwise = noUnfolding
```⊥https://gitlab.haskell.org/ghc/ghc/-/issues/20313Should we inline constructor wrappers into boring contexts?2021-09-02T16:07:30ZAndreas KlebingerShould we inline constructor wrappers into boring contexts?While working on other things I came across this constructor wrapper:
```
-- RHS size: {terms: 7, types: 6, coercions: 0, joins: 0/0}
GHC.Unit.Types.$WRealUnit [InlPrag=INLINE[final] CONLIKE]
:: forall uid. Definite uid %1 -> GenUnit ...While working on other things I came across this constructor wrapper:
```
-- RHS size: {terms: 7, types: 6, coercions: 0, joins: 0/0}
GHC.Unit.Types.$WRealUnit [InlPrag=INLINE[final] CONLIKE]
:: forall uid. Definite uid %1 -> GenUnit uid
[GblId[DataConWrapper],
Arity=1,
Caf=NoCafRefs,
Str=<SL>,
Cpr=1,
Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True,
WorkFree=True, Expandable=True,
Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False)
Tmpl= \ (@uid_a2UY)
(conrep_a3pk [Occ=Once1] :: Definite uid_a2UY) ->
case conrep_a3pk of conrep_X0 [Occ=Once1] { __DEFAULT ->
GHC.Unit.Types.RealUnit @uid_a2UY conrep_X0
}}]
GHC.Unit.Types.$WRealUnit
= \ (@uid_a2UY) (conrep_a3pk [Occ=Once1] :: Definite uid_a2UY) ->
case conrep_a3pk of conrep_X0 [Occ=Once1] { __DEFAULT ->
GHC.Unit.Types.RealUnit @uid_a2UY conrep_X0
}
```
There are a few cases where this kind of wrapper does not get inlined. For example here:
```
case ds8_saQo sat_saQs GHC.Prim.void# of {
Solo# ipv12_saQv [Occ=Once1] ->
let {
sat_saQw [Occ=Once1]
:: GHC.Unit.Types.GenUnit GHC.Unit.Types.UnitId
[LclId] =
{ipv12_saQv} \u [] GHC.Unit.Types.$WRealUnit ipv12_saQv;
} in Solo# [sat_saQw];
```
This is all expected (see the boring_ok=False attribute). I do wonder if it's the right thing to do.
In the example above we will generate a CMM function for the binding `sat_saQw`. This means we pay the overhead of two function calls when evaluating `sat_saQw` but save a bit in code size/compile time.
Things are different for wrappers which evaluate multiple arguments, these can become non-trivial in code size and probably *shouldn't* be inlined into boring contexts.
It seems like there are pros and cons for either choice. We could also make it dependent on the number of cases inside the wrapper. But currently there is no reason given in any of the notes for doing it one way or another. So I'm opening this ticket in case anyone wonders about the current choice or wants to evaluate it going forward.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/20311Pattern match warnings suggest internal constructors2022-05-27T10:33:08ZBinderDavidPattern match warnings suggest internal constructors## Summary
The pattern-match exhaustiveness checker displays a list of non-matched constructors which are internal and shouldn't be displayed. I have checked the issues tagged with "pattern match warnings" in the issue tracker and haven...## Summary
The pattern-match exhaustiveness checker displays a list of non-matched constructors which are internal and shouldn't be displayed. I have checked the issues tagged with "pattern match warnings" in the issue tracker and haven't found a similar issue.
## Steps to reproduce
Compile the following snippet with `-Wall` or `-Wincomplete-patterns`.
```haskell
module Compiler where
import Data.Map
type Var = String
data Prim = Mult | Add
data Term = Var Var
| BinaryPrim Term Prim Term
type Heap = Map Var Term
type State = (Heap, Term)
stepVar :: State -> Maybe State
stepVar (h, Var v) = if member v h
then Just (h, h ! v)
else Nothing
```
This produces the following warning:
```
Compiler.hs:17:1: warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In an equation for ‘stepVar’:
Patterns not matched:
((Data.Map.Internal.Bin _ _ _ _ _), (BinaryPrim _ _ _))
(Data.Map.Internal.Tip, (BinaryPrim _ _ _))
|
17 | stepVar (h, Var v) = if member v h
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
```
## Expected behavior
The internal implementation of Map in terms of Tip and Bin should not be made visible to the user. Importing the internal modules and pattern matching on Bin and Tip is almost always the wrong solution, and especially confusing for newcomers.
The expected warning should look like this:
```
Compiler.hs:17:1: warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In an equation for ‘stepVar’:
Patterns not matched:
(_, (BinaryPrim _ _ _))
|
17 | stepVar (h, Var v) = if member v h
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
```
## Environment
* GHC version used: 8.10.4⊥https://gitlab.haskell.org/ghc/ghc/-/issues/20299Add `primitive` as a boot dependency2023-01-04T08:07:35ZSebastian GrafAdd `primitive` as a boot dependencyThere are 4 basic options in the Hackage ecosystem when you need an array data structure:
1. The `array` package (already a boot dependency of GHC). The wired-in use of `Ix` makes the API much harder to use and more bloated than necessa...There are 4 basic options in the Hackage ecosystem when you need an array data structure:
1. The `array` package (already a boot dependency of GHC). The wired-in use of `Ix` makes the API much harder to use and more bloated than necessary, just to accomodate rare use cases such as `(Int, Int, Int)` indices or pretending that indices don't start from 0. The lack of beign able to say in `Ix` lingo that "this is one past the last index" means we have to fight with off-by-one errors when allocating an Array (`newArray_ (0, len-1)`) for example. It's just a bloated and bad API all around.
2. Use `Array#` primops from GHC.Exts directly. Bad choice, because you have to wrap all mutating operations in `IO`/`ST`. And even if you do that locally in your module, you can't export an `Array#` because then callers have to deal with the same mess, too. So you'll have to extract everything into a utility module that wraps around `Array#`.
3. All this wrapping of `Array#` and `SmallArray#` (which we'd like to have in #18927) has already been done by the `primitive` package (not currently a boot dependency). So we could copy most of the stuff from there. But then why not simply depend on `primitive` in the first place?
4. The `vector` package (not currently a boot dependency of GHC). Basically `array` done right, a higher-level API around `primitive`'s `Data.Primitive.Array` wrapper. If we depend on `vector` we implicitly depend on `primitive`, so we might as well stick to `primitive`.
5. Other even higher-level array types such as those from `repa`. Serve an entirely different purpose, I just want a linear chunk of memory.
At the moment, we only have option (1) or (2) in GHC. I dislike both, to the point that I always hesitate to reach out to arrays when I better should. The obvious choice here is (3), a new boot depenency on `primitive`, that is. Here is some motivation:
1. Unlike now, I'd try to use an array in new code where an array would make sense, simply because I could import the API of `Data.Primitive.Array` and `Data.Primitive.SmallArray`.
2. https://gitlab.haskell.org/ghc/ghc/-/issues/18927 provides some existing use cases for `SmallArray#`
3. I think even if the length of the list that we (otherwise) build up is not known in advance or even fixed, we would benefit from continuously (à la [`std::vector::push_back`](https://www.cplusplus.com/reference/vector/vector/push_back/) or even [`std::deque::push_back`](https://www.cplusplus.com/reference/deque/deque/push_back/)) building up an array rather than a list. Keep in mind that each new cons cell has an overhead of 3 words; even growing a `std::vector` when out of capacity by a factor of 2 has less than 2 words of overhead and allows O(1) random access and length at the same time. The huge win of using lists is simplicity and fusion; the latter can be achieved for arrays, too (see https://gitlab.haskell.org/ghc/ghc/-/issues/18927#note_312644), while the former is a matter of providing good pattern synonyms for slices of arrays.
4. There is other useful stuff in `primitive`, such as abstraction over `PrimMonad` (which has `ST` and `IO` instances)
What are the drawbacks?
1. We'd have to maintain one more boot package. Given that `vector` is already quite a prominent Core package and that `vector` depends on `primitive`, I would think that the difference isn't too huge. Besides, we already have to provide `primitive` patches for the head.hackage overlay today, otherwise most of the ecosystem wouldn't even build. Patching `primitive` as part of an MR that breaks it probably means *less* maintenance overhead overall.
2. Longer time to bootstrap. Fair enough.
3. Intellectual overhead from using `PrimMonad` abstractions and other stuff we have to get used to. I don't think there's anything quite so complicated in the package that would pose a problem.
To me the cost/benefit ratio is clearly >1, so I propose to add `primitive` as a boot dependency. I hereby ask for permission to do so.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/20197Provide Ord/Eq instances for all tuple instances.2021-08-03T11:45:01ZAndreas KlebingerProvide Ord/Eq instances for all tuple instances.There was an MR a while ago to do this which sadly had some performance issues that were not ironed out.
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3369
It might still be good to provide this instances, or if not at least find...There was an MR a while ago to do this which sadly had some performance issues that were not ironed out.
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3369
It might still be good to provide this instances, or if not at least find out why performance goes south when we add them.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/20032Make a separate test package for reqlib tests which is run by head.hackage2021-12-23T08:55:15ZMatthew PickeringMake a separate test package for reqlib tests which is run by head.hackageTODOTODO⊥Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/19907Warnings(?) about overlapping rules when building a debugged GHC2021-08-10T06:35:19ZAndreas KlebingerWarnings(?) about overlapping rules when building a debugged GHCFor a bit of time now I noticed that when I build a debugged + optimized GHC that I get a lot of warnings of the sort:
```
Rules.findBest: rule overlap (Rule 1 wins)
Rule 1: "fromIntegral/a->Word32"
Rule 2: "fromIntegral/CInt->a"
Ru...For a bit of time now I noticed that when I build a debugged + optimized GHC that I get a lot of warnings of the sort:
```
Rules.findBest: rule overlap (Rule 1 wins)
Rule 1: "fromIntegral/a->Word32"
Rule 2: "fromIntegral/CInt->a"
Rules.findBest: rule overlap (Rule 1 wins)
Rule 1: "fromIntegral/a->Word32"
Rule 2: "fromIntegral/CInt->a"
Rules.findBest: rule overlap (Rule 1 wins)
Rule 1: "fromIntegral/Word32->a"
Rule 2: "fromIntegral/a->CInt"
Rules.findBest: rule overlap (Rule 1 wins)
Rule 1: "fromIntegral/a->Word32"
Rule 2: "fromIntegral/CInt->a"
Rules.findBest: rule overlap (Rule 1 wins)
Rule 1: "fromIntegral/Word32->a"
Rule 2: "fromIntegral/a->CInt"
```
At worst that's an indication for an issue with our rules.
At best it's a lot of noise that might obscure more important debugging traces.
Either way the current state doesn't seem to be desireable. Maybe something could be done about that.
I think it started with https://gitlab.haskell.org/ghc/ghc/commit/d8dc0f96237fe6fe7081c04727c7c2573477e5cb
Which added rules like:
```
"fromIntegral/a->Word32" fromIntegral = \x -> case fromIntegral x of W# x# -> W32# (wordToWord32# x#)
```
which overlaps with the much older rules like this one:
```
"fromIntegral/CInt->a" fromIntegral = \(CInt x) -> fromIntegral x
```
The overlap seems to be harmless in this case. So perhaps we just have to live with that. But it does come at the cost of making the debug output less useful.
@hsyl20 Given that you added them maybe you have an idea how to avoid the status quo?⊥https://gitlab.haskell.org/ghc/ghc/-/issues/19863Darwin build logs contain a lot of errors about unused command line parameters2021-06-18T11:13:58ZMatthew PickeringDarwin build logs contain a lot of errors about unused command line parametersSee https://gitlab.haskell.org/ghc/ghc/-/jobs/678361
There are hundreds of lines of
```
clang-7: warning: argument unused during compilation: '-iframework /nix/store/6cigdqyph0v0anv7d0iax6q3p24qy4kl-apple-framework-Accelerate/Library/F...See https://gitlab.haskell.org/ghc/ghc/-/jobs/678361
There are hundreds of lines of
```
clang-7: warning: argument unused during compilation: '-iframework /nix/store/6cigdqyph0v0anv7d0iax6q3p24qy4kl-apple-framework-Accelerate/Library/Frameworks' [-Wunused-command-line-argument]
clang-7: warning: argument unused during compilation: '-iframework /nix/store/6cigdqyph0v0anv7d0iax6q3p24qy4kl-apple-framework-Accelerate/Library/Frameworks' [-Wunused-command-line-argument]
clang-7: warning: argument unused during compilation: '-iframework /nix/store/30b67i71n343q3hqd2mx091pjlriia4w-apple-framework-CoreWLAN/Library/Frameworks' [-Wunused-command-line-argument]
clang-7: warning: argument unused during compilation: '-iframework /nix/store/30b67i71n343q3hqd2mx091pjlriia4w-apple-framework-CoreWLAN/Library/Frameworks' [-Wunused-command-line-argument]
clang-7: warning: argument unused during compilation: '-iframework /nix/store/86xmn84cpnra5n8s6ak4iwg3yq0pcjw6-apple-framework-SecurityFoundation/Library/Frameworks' [-Wunused-command-line-argument]
clang-7: warning: argument unused during compilation: '-iframework /nix/store/86xmn84cpnra5n8s6ak4iwg3yq0pcjw6-apple-framework-SecurityFoundation/Library/Frameworks' [-Wunused-command-line-argument]
```⊥https://gitlab.haskell.org/ghc/ghc/-/issues/19833W/W: Try removing the use of zapUsedOnceInfo2021-06-21T08:56:00ZAndreas KlebingerW/W: Try removing the use of zapUsedOnceInfoSPJ wondered if WW could perhaps stop zapping the usedOnceInfo.
> But in any case, as you'll see above, I'm now questioning the need for `zapUsedOnceInfo` at all! Could you try the effect of removing it?
The details/reasons is containe...SPJ wondered if WW could perhaps stop zapping the usedOnceInfo.
> But in any case, as you'll see above, I'm now questioning the need for `zapUsedOnceInfo` at all! Could you try the effect of removing it?
The details/reasons is contained in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5710#note_351333 and the comments below.
Opening this ticket so the idea isn't lost to time.
The assume the biggest benefit would be likely that we no longer do the work of zapping these ids. Perhaps simplification after W/W would also benefit but it's hard to tell.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/19826`Note [NOINLINE someNatVal]` possibly outdated?2021-05-12T22:00:29Zvdukhovni`Note [NOINLINE someNatVal]` possibly outdated?## Summary
In [GHC.TypeNats](https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/TypeNats.hs#L93-147) the `NOINLINE someNatVal` note talks about care around use of `Any` in the definition of `someNatVal`, with additional...## Summary
In [GHC.TypeNats](https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/TypeNats.hs#L93-147) the `NOINLINE someNatVal` note talks about care around use of `Any` in the definition of `someNatVal`, with additional related text in [`GHC.HsToCore.Expr`](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/HsToCore/Expr.hs#L1414-1423).
But actual use of `Any` in combination with `withDict` is nowhere to be found in either the compiler or the base library.
Only the testsuite appears to contain such usage:
```
testsuite/tests/ghci/scripts/T19667Ghci.hs--- See Note [NOINLINE someNatVal] in GHC.TypeNats
testsuite/tests/ghci/scripts/T19667Ghci.hs-{-# NOINLINE reifySymbol #-}
testsuite/tests/ghci/scripts/T19667Ghci.hs-reifySymbol :: forall r. String -> (forall (n :: Symbol). KnownSymbol n => Proxy n -> r) -> r
testsuite/tests/ghci/scripts/T19667Ghci.hs:reifySymbol n k = withDict @(SSymbol Any) @(KnownSymbol Any) (SSymbol n) (k @Any) (Proxy @(Any @Symbol))
--
testsuite/tests/typecheck/should_fail/T16646Fail.hs-reify :: forall a r. a -> (forall (s :: Type). Reifies s a => Proxy s -> r) -> r
testsuite/tests/typecheck/should_fail/T16646Fail.hs:reify a k = withDict @_ @(Reifies (Any @Type) a) (const a) (k @Any) Proxy
--
testsuite/tests/typecheck/should_run/T16646.hs-reify :: forall a r. a -> (forall (s :: Type). Reifies s a => Proxy s -> r) -> r
testsuite/tests/typecheck/should_run/T16646.hs-{-# NOINLINE reify #-} -- See Note [NOINLINE someNatVal] in GHC.TypeNats
testsuite/tests/typecheck/should_run/T16646.hs:reify a k = withDict @(forall (proxy :: Type -> Type). proxy Any -> a)
testsuite/tests/typecheck/should_run/T16646.hs- @(Reifies (Any @Type) a)
testsuite/tests/typecheck/should_run/T16646.hs- (const a) (k @Any) Proxy
--
testsuite/tests/typecheck/should_run/T19667.hs--- See Note [NOINLINE someNatVal] in GHC.TypeNats
testsuite/tests/typecheck/should_run/T19667.hs-{-# NOINLINE reifySymbol #-}
testsuite/tests/typecheck/should_run/T19667.hs-reifySymbol :: forall r. String -> (forall (n :: Symbol). KnownSymbol n => Proxy n -> r) -> r
testsuite/tests/typecheck/should_run/T19667.hs:reifySymbol n k = withDict @(SSymbol Any) @(KnownSymbol Any) (SSymbol n) (k @Any) (Proxy @(Any @Symbol))
```
Even the `reflection` package does not appear to be explicitly using `Any` anywhere obvious.
I find this somewhat confusing...⊥https://gitlab.haskell.org/ghc/ghc/-/issues/19823Hadrian built stage1 compiler complains about missing `#define HS_CONSTANTS`2021-08-26T11:06:33ZAndreas KlebingerHadrian built stage1 compiler complains about missing `#define HS_CONSTANTS`In the past I was able to run the stage0 compiler using a invocation like this:
`_validatebuild/stage0/bin/ghc.exe ~/tmp/C.hs -O -fforce-recomp -package-db _validatebuild/stage0/lib/package.conf.d/`
But that seems to have broken recent...In the past I was able to run the stage0 compiler using a invocation like this:
`_validatebuild/stage0/bin/ghc.exe ~/tmp/C.hs -O -fforce-recomp -package-db _validatebuild/stage0/lib/package.conf.d/`
But that seems to have broken recently. I tried running the stage0 compiler manually today and got the above mentioned error.
This is new and quite bothersome!⊥Sylvain HenrySylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/19665Incompleteness of solving: D/N cannot rewrite D/R2022-02-23T13:21:43ZRichard Eisenbergrae@richarde.devIncompleteness of solving: D/N cannot rewrite D/RIf we try
```hs
data T a
type role T nominal
type family F a
g :: forall b a. (F a ~ T a, Coercible (F a) (T b)) => ()
g = ()
f :: forall a. (F a ~ T a) => ()
f = g @a
```
This fails because GHC cannot figure out how to instantiate ...If we try
```hs
data T a
type role T nominal
type family F a
g :: forall b a. (F a ~ T a, Coercible (F a) (T b)) => ()
g = ()
f :: forall a. (F a ~ T a) => ()
f = g @a
```
This fails because GHC cannot figure out how to instantiate the `a` in the type of `g`. (The `b` gets instantiated to `f`'s `a`.)
We have
```
[G] F a ~N T a
[WD] F alpha ~N T alpha
[WD] F alpha ~R T a
```
The Wanteds aren't of use, so let's just look at Deriveds:
```
[G] F a ~N T a
[D] F alpha ~N T alpha
[D] F alpha ~R T a
```
We would like to use the first Derived to rewrite the second. We would then have `T alpha ~R T a`, which can decompose to `alpha ~N a` (given the nominal annotation on `T`). We set `alpha := a` and off we go.
The problem is that a Derived/Nominal equality will not rewrite a Derived/Representational one. See Definition [Can-rewrite relation] in
GHC.Tc.Solver.Monad, in particular R2, which would be violated if D/N could rewrite D/R.
We thus accept this bug as an infelicity, not knowing how to do better for now.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/19516CoreLint lints all top-level bindings as recursive bindings2021-05-26T16:11:55ZSebastian GrafCoreLint lints all top-level bindings as recursive bindingsAt the moment, `lintCoreBindings` calls `lintRecBindings` for all the top-level bindings, which means that top-level non-recursive bindings are linted as top-level recursive bindings.
That in turn shows in !2218, where CoreLint trips up...At the moment, `lintCoreBindings` calls `lintRecBindings` for all the top-level bindings, which means that top-level non-recursive bindings are linted as top-level recursive bindings.
That in turn shows in !2218, where CoreLint trips up on top-level bindings for DataCon workers and wrappers after CorePrep. These bindings are ok-for-spec, so CoreLint wouldn't trigger if they were correctly linted as non-recursive.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/19331Add a GHC flag for making every functions in a module inlinable2021-10-27T13:09:45ZPoscatAdd a GHC flag for making every functions in a module inlinable## Motivation
When writing code that uses transformer-based effect systems (`mtl`, `fused-effects`). We often need to specialize functions at call sites since functions with unknown monad prevent other optimizations (inlining `>>=`, `as...## Motivation
When writing code that uses transformer-based effect systems (`mtl`, `fused-effects`). We often need to specialize functions at call sites since functions with unknown monad prevent other optimizations (inlining `>>=`, `ask`, `get` ...). To ensure that happens we need to mark every function inlinable which is very tedious. It would be great to add a GHC flag that does this.
## Proposal
Add a GHC flag for making every functions in a module inlinable⊥https://gitlab.haskell.org/ghc/ghc/-/issues/17969The haddocks for `sortWith` should give guidance about when it's prefered ove...2024-01-21T12:06:26ZAndreas KlebingerThe haddocks for `sortWith` should give guidance about when it's prefered over `sortOn`As ben explained it somewhere else:
> In general if the mapping function is expensive to compute then you should probably be using `sortOn`, as it only needs to compute it once for each element. `sortWith`, on the other hand must comput...As ben explained it somewhere else:
> In general if the mapping function is expensive to compute then you should probably be using `sortOn`, as it only needs to compute it once for each element. `sortWith`, on the other hand must compute the mapping function for every comparison that it performs. Beyond that general intuition it's hard to give any specific prescription.
I think even without more specific guidance stating this much in the docs would be good.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/17795Optimize repeated usage of instance methods.2020-02-18T16:18:30ZAndreas KlebingerOptimize repeated usage of instance methods.## Motivation
Consider this code:
```haskell
class C a where
op1 :: a -> a
op2 :: a -> a -> a
foo :: C a => a -> a -> a
foo x y =
op1 x `op2` op1 y
```
In the absence of specialization I expected `op1` and `op2` to be ext...## Motivation
Consider this code:
```haskell
class C a where
op1 :: a -> a
op2 :: a -> a -> a
foo :: C a => a -> a -> a
foo x y =
op1 x `op2` op1 y
```
In the absence of specialization I expected `op1` and `op2` to be extracted once from the constraint/dictionary and to be reused for each use.
Instead we currently extract the methods once per use:
```haskell
foo :: forall a. C a => a -> a -> a
[GblId,
Arity=3,
Caf=NoCafRefs,
Str=<S,U><L,U><L,U>, Unf=<irrelevant>
foo
= \ (@a_aAq)
($dC_aAs :: C a_aAq)
(x_agS :: a_aAq)
(y_agT :: a_aAq) ->
op2
@a_aAq
$dC_aAs
((op1 @a_aAq $dC_aAs) x_agS)
((op1 @a_aAq $dC_aAs) y_agT)
```
This isn't cheap as it causes a bunch of unknown calls and jumping back and forth. (On the plus side it doesn't allocate at least).
Even if we manually bind op1 to a name the simplifier will happily inline it again, duplicating the work performed.
## Proposal
Ideally we would translate `op1 x `op2` op1 y` from above into
```haskell
let o = op1 @a_aAq $dC_aAs
in o x `op2` o y
```
The problems preventing this are:
* We desugar into the form `op1 x `op2` op1 y` quite early.
* Even if we don't the simplifier will inline `o` as `op1` is considered cheap.
* Instances currently generate rules which will match on `op1 @a_aAq $knownDict x_agS`. If the dictionary is known, the rule will replace it with `op1_instance @a_aAq $knownDict x_agS`. This would break under the form above.
* While the let for `o` can usually be turned into a (non-allocating) case this is not guaranteed. Allocating might be worse than the duplicated work.
I don't think this is a big problem in practice.
If performance really matters we would always want the above snippet to specialize so the overhead can disappear completely.
If performance doesn't really matter then neither does it if we do a little extra work.
So while I don't intend to work on this anytime soon it seemed reasonable to document this behaviour.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/17128Investigate encoding recursive demand types2020-06-07T14:19:56ZSebastian GrafInvestigate encoding recursive demand types@jmct brought up an interesting point in https://gitlab.haskell.org/ghc/ghc/issues/12364#note_122148 that I just came to remember today: Instead of cutting off strictness/usage/nested CPR analysis information at some arbitrary cut-off in...@jmct brought up an interesting point in https://gitlab.haskell.org/ghc/ghc/issues/12364#note_122148 that I just came to remember today: Instead of cutting off strictness/usage/nested CPR analysis information at some arbitrary cut-off in fixed-point iteration, we should try to encode the recursive nature in the lattice instead. If all went well, we are able to encode the subset of *regular* recursive types (in the sense of i.e. TAPL 21.8. [Here's the gist of it](https://gitlab.haskell.org/ghc/ghc/issues/17128#note_219722)), for which I'm pretty confident we can define equality and lattice operations. According to the comment above, we'll have problems with polymorphic recursion, but I'm not ready to give in on this yet.
Implementing recursive lattices would allow faster termination of fixed-point iteration, while also providing the perfect amount of information! To make this more concrete, let's say we augment the nested CPR lattice with
```
data Cpr
= ...
| CprVar Unique
| CprFix Unique Cpr
```
Apart from introducing all kinds of well-formedness problems, here's an example that shows their usefulness (there are probably more compelling examples somewhere out in the wild):
```
repeat :: a -> [a]
repeat x = x : repeat x
```
`repeat` has an infinitely deep CPR property, captured by `μX.(-,X)`. I'm using some new syntax from my nested CPR branch here, where `-` encodes Top and `(,)` a constructed pair. The term above would correspond to `CprFix 42 (CprProd [CprTop, CprVar 42])` in our embedding. This is at the same time much more expressive than cutting off at depth, say, 3, corresponding to `(-,(-,(-,-)))`, and also more efficient, since fixed-point iteration will stabilise after the second iteration. Here's the trace of `repeat`s CprType over each fixed-point iteration, under the assumption we introduced a fresh variable X standing for `repeat`:
```
initially:
. -> . -> μX.X <-- this is probably similar/equivalent to bottom?! Not sure about the scope of X
after iteration #1:
. -> . -> μX.(-, X)
after iteration #2, reaching the fixed-point:
. -> . -> μX.(-, X)
```
Turns out I'm not really able to express the proper formalism/lattice here, so this needs some more thinking. But I think this should be the general story.⊥