GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-08-23T14:25:43Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/22095template-haskell: Make it easier to define an instance of Quasi2022-08-23T14:25:43ZTeo Camarasutemplate-haskell: Make it easier to define an instance of Quasi<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appr...<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appropriate for a GitLab feature request, include GHC API/plugin
innovations, new low-impact compiler flags, or other similar additions to GHC.
-->
## Motivation
It's currently quite laborious to give a definition of `Quasi` as it has 26 required methods.
This is somewhat ameliorated by the `th-orphans` package that gives instances for ReaderT, StateT, WriterT and RWST.
## Proposal
Define a new typeclass:
```
class LiftQ m where
liftQ :: Q a -> m a
```
and define default methods for all of the methods of `Quasi` except for `qRecover` in terms of that class lifting the operation from `Q`.
`qRecover` is a special case as there's non-trivial decisions to be made as to how you want to recover from an error.
I'm not sure if this is worthwhile but I felt like it was at least worth raising.
Take a look here to [see ](https://hackage-search.serokell.io/?q=instance.*Quasi)Quasi instances on hackage.https://gitlab.haskell.org/ghc/ghc/-/issues/21856Performance considerations in the age of SPECTRE and Retbleed2022-07-19T14:42:52ZHécate MoonlightPerformance considerations in the age of SPECTRE and RetbleedThis is an open discussion regarding the mitigation costs incurred by the patches made to the Linux kernel regarding the Retbleed vulnerability.
See a summary here: https://comsec.ethz.ch/research/microarch/retbleed/
and the paper h...This is an open discussion regarding the mitigation costs incurred by the patches made to the Linux kernel regarding the Retbleed vulnerability.
See a summary here: https://comsec.ethz.ch/research/microarch/retbleed/
and the paper here: https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf
One paragraph is particular of interest:
> Our performance evaluation shows that mitigating Retbleed has unfortunately turned out to be expensive: we have measured between **14%** and **39%** overhead with the AMD and Intel patches respectively. Please refer to the paper if you want to know more. Mitigating Phantom JMPs with a generic flushing of the branch predictor unit on kernel transitions imposes up to **209%** performance overhead.
This is not great, and as we are slowly (but surely) exiting the era of "software engineers write software, hardware engineers make software go fast", it is my opinion that we should invest in optimising the programs generated by the compiler to keep up with the stop of infinite growth by hardware chips.
This is not something that lives in a vacuum, as GHC's own memory and CPU footprint have long been decried. If we wish to onboard new demographics that do not have easy access to 32GB of RAM and ThreadRippers to compensate for GHC's usage cost **and** the several kernel and CPU mitigations against the vulnerabilities of the SPECTRE family, we must invest in making our beloved compiler more lightweight and kind to our hardware.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20971Attach arbitrary data to CallStack2022-02-28T14:37:09ZJoachim Breitnermail@joachim-breitner.deAttach arbitrary data to CallStackSometimes I would love to have a function
```
pushCallStackAnnotation :: String -> CallStack -> CallStack
```
that pushes arbitrary extra information to the `CallStack` (e.g. the value of some parameter).
The impact would be some brea...Sometimes I would love to have a function
```
pushCallStackAnnotation :: String -> CallStack -> CallStack
```
that pushes arbitrary extra information to the `CallStack` (e.g. the value of some parameter).
The impact would be some breaking changes around `CallStack` (because it wouldn’t be a `[(String, SrcLoc)]` anymore), and in a way it’s a dangerous feature, because if overused it might cause programs to keep more data alive than expected. But in some cases it could really help with debugging, I expect.https://gitlab.haskell.org/ghc/ghc/-/issues/20422Implement System.timeoutWithUnmask as a way to document the deficiency of ord...2021-10-11T09:59:22ZMikolaj KonarskiImplement System.timeoutWithUnmask as a way to document the deficiency of ordinary System.timeoutThe goal is to document the unobvious problem that expressions like `timeout 1000 takeMVar`, when executed in a loop, lead to data loss. Namely, the IO action (consisting of `takeMVar`) may be interrupted just after `takeMVar` finishes a...The goal is to document the unobvious problem that expressions like `timeout 1000 takeMVar`, when executed in a loop, lead to data loss. Namely, the IO action (consisting of `takeMVar`) may be interrupted just after `takeMVar` finishes and so consumes the value put into the `MVar`, giving `Nothing` as the result of the whole timeout expression. That's despite `takeMVar` being atomic and `timeout` being subtle and expensive. In the attached program around 15% of the data is lost with timeout 1 and `-threaded` for me.
This ticket is about implementing System.timeoutWithUnmask (sibling of forkIOwithUnmask), proposed by @duog, that prevents data loss in calls such as `timeoutWithUnmask $ \_restore -> takeMVar mv`. The documentation would point out the difference and suggest to switch to STM for a more extensible solution using `registerDelay` (see https://stackoverflow.com/questions/22171895/using-tchan-with-timeout/22182074). As suggested by @duog, the general usage pattern of `timeoutWithUnmask` would be `timeoutWithUnmask $ \restore -> do { r <- restore $ expensive; cheap r; }`.
Another angle is to implement `tryTakeMVarWithTimeout` and cross-reference explaining why `flip timeout takeMVar` is not equivalent by far.
Here's the file showing the data loss (and an occassional lock-up for an analogous reason):
[timeoutTest.hs](/uploads/87f457fe5c85188d39fdc84debc419f0/timeoutTest.hs)https://gitlab.haskell.org/ghc/ghc/-/issues/18830Can't use NamedFieldPuns and ScopedTypeVariables together2022-05-31T06:51:35ZGeorgi LyubenovCan't use NamedFieldPuns and ScopedTypeVariables together## Motivation
I believe there is a "hole" in interactions between `NamedFieldPuns` and `ScopedTypeVariables`.
```haskell
{-# LANGUAGE NamedFieldPuns, ScopedTypeVariables #-}
data X a = X {field :: Y a}
data Y a
f :: X a -> ...
f X {f...## Motivation
I believe there is a "hole" in interactions between `NamedFieldPuns` and `ScopedTypeVariables`.
```haskell
{-# LANGUAGE NamedFieldPuns, ScopedTypeVariables #-}
data X a = X {field :: Y a}
data Y a
f :: X a -> ...
f X {field :: Y a} = ...
```
This is currently not a valid way (doesn't parse) to bind type variables.
## Proposal
I propose that
```haskell
f X {field :: Y a} = ...
```
desugar(?) to
```haskell
f X {field = field :: Y a} = ...
```https://gitlab.haskell.org/ghc/ghc/-/issues/17015More general Eq+Ord+Read+Show instances for Data.Functor.Product2019-09-11T14:37:19ZyairchuMore general Eq+Ord+Read+Show instances for Data.Functor.Product## Motivation
`Data.Functor.Product` currently has instances for `Eq`, `Ord`, `Read`, and `Show` which are based on `Eq1`, `Ord1`, `Read1`, and `Show1`, which implicitly assume that:
* The `a` type variable in `Product f g a` has a rep...## Motivation
`Data.Functor.Product` currently has instances for `Eq`, `Ord`, `Read`, and `Show` which are based on `Eq1`, `Ord1`, `Read1`, and `Show1`, which implicitly assume that:
* The `a` type variable in `Product f g a` has a representational role
* The `f` and `g` type variables have kind `Type -> Type`
These assumptions are not always correct, for example:
* There's no reason that `Eq (Product (Const Int) (Const Bool) a)` should require `Eq a`, but it does
* `PolyKinds` instances of `Product` can't currently have `Eq` instances because `Eq1` can't be provided for `f` because it has the wrong kind
When needing these instances, the problem currently cannot be worked around using orphan instances, as those overlap the original instances.
## Proposal
Replace the current limited `Eq`, `Ord`, `Read`, and `Show` instances of `Product` with more general instances.
This is a matter of simply removing the current instances and adding `, Eq, Ord, Read, Show` to `Product`'s `deriving` clause.https://gitlab.haskell.org/ghc/ghc/-/issues/16894TypeError hides a second error message2020-01-23T19:40:11ZJoey HessTypeError hides a second error message# Summary
Using TypeError seems to hide other type error messages due to eg, bad arguments passed to a function.
# Steps to reproduce
Load into ghci:
```
{-# LANGUAGE DataKinds, UndecidableInstances, TypeFamilies #-}
import...# Summary
Using TypeError seems to hide other type error messages due to eg, bad arguments passed to a function.
# Steps to reproduce
Load into ghci:
```
{-# LANGUAGE DataKinds, UndecidableInstances, TypeFamilies #-}
import GHC.TypeLits
type family Check x :: Bool where
Check 'True = 'True
Check x = 'False
foo :: Check 'False ~ 'True => Int -> String
foo n = "never reached"
type family Check2 x :: Bool where
Check2 'True = 'True
Check2 x = TypeError ('Text "no")
foo2 :: Check2 'False ~ 'True => Int -> String
foo2 n = "never reached"
```
```
ghci> foo "bar"
<interactive>:69:1: error:
• Couldn't match type ‘'False’ with ‘'True’
arising from a use of ‘foo’
• In the expression: foo "bar"
In an equation for ‘it’: it = foo "bar"
<interactive>:69:5: error:
• Couldn't match expected type ‘Int’ with actual type ‘[Char]’
• In the first argument of ‘foo’, namely ‘"bar"’
In the expression: foo "bar"
In an equation for ‘it’: it = foo "bar"
ghci> foo2 "bar"
<interactive>:70:1: error:
• no
• In the expression: foo2 "bar"
In an equation for ‘it’: it = foo2 "bar"
```
# Expected behavior
I expected to see the same error about Int vs [Char] for foo2 as is shown for foo, as well as the custom TypeError. However, the use of TypeError somehow prevents the Int vs [Char] error from being displayed.
This is preventing me from using TypeError in situations where there might be another, more basic
type error in the same code.
This may be related to https://gitlab.haskell.org/ghc/ghc/issues/14771
# Environment
* GHC version used: 8.4.4, 8.6.5