GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-09-07T14:24:46Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/20337Projecting existential variables2021-09-07T14:24:46ZJohn EricsonProjecting existential variableshttps://richarde.dev/papers/2021/exists/exists.pdf shows how we can project existential variables, using the expressions themselves to "non-generatively" introduce special skolems, rather than be confined to pattern matching and getting ...https://richarde.dev/papers/2021/exists/exists.pdf shows how we can project existential variables, using the expressions themselves to "non-generatively" introduce special skolems, rather than be confined to pattern matching and getting fresh skolems confined to scopes. These "applicative skolems" (to continue to borrow the ML functor terminology), are a nice thing to have with or without `exists a. ...` new "structural" existential types.
With lots of other hypothetical syntax:
```haskell
data Foo where
MkFoo :: forall a. Show a => a :: Foo
_1 :: Foo -> Type -- but indicate non-relevant somehow?
_2 :: forall (a :: Foo) -> Dict (Show (fst a))
_3 :: forall (a :: Foo) -> fst a
foo :: Foo -> String
foo f = case _2 a of
Dict -> show x
where
type T = _1 a
x :: T = _3 a
```
`_2` requires `case`, but that is only because of `Dict`. We could imagine explicit dictionary arguments or something instead, but that is separate.
The paper also goes into term-level constraints, which seems good for Dependent Haskell in general, but I suppose that should also have a separate issue.
CC @raeResearch neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/20323RFC: Using llvm-hs in GHC2021-09-13T09:22:49Zandrew.wjaRFC: Using llvm-hs in GHCHi folks, newish [llvm-hs](https://github.com/llvm-hs/llvm-hs) maintainer here -- while preparing the llvm-hs-12.0.0.0 release I was doing a survey of projects using llvm-hs, and GHC is a very notable exception. I'm just wondering why GH...Hi folks, newish [llvm-hs](https://github.com/llvm-hs/llvm-hs) maintainer here -- while preparing the llvm-hs-12.0.0.0 release I was doing a survey of projects using llvm-hs, and GHC is a very notable exception. I'm just wondering why GHC still uses a hand-rolled LLVM backend.
I would like to take care not to imply that I think a) anything is wrong with, or b) "something should be done" about, the GHC LLVM backend -- I'm just curious to know whether anyone has thought about or investigated alternatives recently. llvm-hs has been around for quite a while, and llvm-general before it, but I think the GHC LLVM backend may predate both.
In particular, if there are things that llvm-hs does not support, or makes awkward to do, it would be great to learn about and fix those issues to improve llvm-hs.
## Motivation
It seems like it would be a win-win if GHC were to use llvm-hs in the CMM to LLVM lowering rather than a hand-rolled abstract syntax. It would mean GHC doesn't have to contain code modelling LLVM entities that needs to be kept in sync with what the upstream LLVM project does. For example, they've added a new instruction kind in the 12.0 release, and an upcoming change will [remove static pointee type information](https://llvm.org/docs/OpaquePointers.html) from pointers.
It also appears that some issues in the GHC LLVM backend may be intrinsically addressed by the approach used in llvm-hs. One that I have seen while looking through the GHC LLVM backend code is the issue of forward references. Because llvm-hs uses a straightforward monad transformer stack to represent code generation, recursive-do handles forward reference of all sorts in a natural way, as in this example: https://github.com/llvm-hs/llvm-hs-examples/blob/master/irbuilder/Main.hs
Since llvm-hs is a two-way binding to the LLVM API and datastructures, you can seamlessly raise and lower entities like modules, functions, etc. between the Haskell AST and the native C++ datastructures. That allows you to do things like invoke LLVM passes on a module, and lift the resulting module back to Haskell to do custom stuff to it, or even to write "native" LLVM passes in Haskell via the FFI, implementing the C++ `runOnModule` method of the pass in Haskell.
## Proposal
Switch to using [llvm-hs](https://github.com/llvm-hs/llvm-hs) for code generation in the GHC LLVM backend.Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/20188Instances for ImpredicativeTypes2021-08-11T12:01:17ZparsonsmattInstances for ImpredicativeTypesNow that we have [ImpredicativeTypes](https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/impredicative_types.html#impredicative-polymorphism) available in a nice way, it'd be cool if we could use them in type class instances.
## Mo...Now that we have [ImpredicativeTypes](https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/impredicative_types.html#impredicative-polymorphism) available in a nice way, it'd be cool if we could use them in type class instances.
## Motivation
I'm playing with `OverloadedRecordDot` and running into the problem that I can't write a polymorphic virtual method. For example:
```haskell
data User = User { name :: String }
instance HasField "showWithName" User (forall a . Show a => a -> String) where
getField self a =
concat [self.name, " : ", show a]
```
What's actually *worse* is that I can't include *any* type variables, at all, so I can't even write, like,
```haskell
instance HasField "identity" User (forall a. a -> a) where
getField _ a =
a
```
## More simply,
Actually, the problem is that we can't write an instance for an impredicative type, at all.
```haskell
{-# Language ImpredicativeTypes, FlexibleInstances #-}
class C a
instance C (forall a . a -> a)
```
This fails with the error message:
```
src/Impl/TH.hs:30:10-30: error:
• Illegal polymorphic type: forall a. a -> a
• In the instance declaration for ‘C (forall a. a -> a)’
|
30 | instance C (forall a . a -> a)
| ^^^^^^^^^^^^^^^^^^^^^
```
I don't know if this is properly a bug or a feature request - on the one hand, I am asking for new functionality, and on the other hand, I am asking for the intersection of existing functionality to work.Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/19862Can't work with symlinked files created in other operating systems2021-05-19T14:16:18ZMatt WalkerCan't work with symlinked files created in other operating systems## Summary
When I create a symlink of a haskell source file into a directory with other source files, `ghc` and `ghci` cannot load a file that was created via a symlink in another operating system
Apologies if this is an OS limitation ...## Summary
When I create a symlink of a haskell source file into a directory with other source files, `ghc` and `ghci` cannot load a file that was created via a symlink in another operating system
Apologies if this is an OS limitation rather than a problem with GHC
## Steps to reproduce
I have created [the following test repo to show the error](https://github.com/matteematt/ghc-symlink-test)
1. I have `lib.hs` in the root
2. In the mac directory I have symlinked the `Lib.hs` file into this directory using MacOS. I then have a main Haskell source file that includes this symlinked file
3. In the linux directory I have symlinked the `Lib.hs` file into this directory using Linux. I then have a main Haskell source file that includes this symlinked file
4. When I try and load the files using `ghc` or `ghci` for the wrong operating system it doesn't work:
For example, on my Mac:
```
ghci Linux.hs
GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /Users/mwa75/.dotfiles/config/haskell/ghci.conf
[1 of 1] Compiling Main ( Linux.hs, interpreted )
Linux.hs:6:17: error: Variable not in scope: test :: String
|
6 | main = putStrLn test
| ^^^^
Failed, no modules loaded.
```
```
ghci Mac.hs
GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /Users/mwa75/.dotfiles/config/haskell/ghci.conf
[1 of 2] Compiling Lib ( Lib.hs, interpreted )
[2 of 2] Compiling Main ( Mac.hs, interpreted )
Ok, two modules loaded.
```
I note the same behaviour on Linux, but its the opposite way around (failing to load the symlinked file created on MacOS but not on Linux)
## Expected behavior
I expect `ghc` and `ghci` to be able to work with symlinked files created on other operating sysytems. The github repo I have linked is a stripped down version of a problem I am actually seeing when trying to create projects cross platform
## Environment
* GHC version used:
The Glorious Glasgow Haskell Compilation System, version 8.8.4
Optional:
* Operating System: MacOS Big Sur 11.3.1 (I was also seeeing the issue on Catalina), Arch Linux (rolling release so always newest version)
* System Architecture: x86_64Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/18811Allow pragmas on field selectors.2020-10-06T16:56:30ZAndreas KlebingerAllow pragmas on field selectors.## Motivation
If we want to allow rules to match on field selectors, we would like to delay them being translated into
pattern matches until the rules had a chance to fire.
Consider this snippet:
```haskell
data T = MkT { foo :: Int }...## Motivation
If we want to allow rules to match on field selectors, we would like to delay them being translated into
pattern matches until the rules had a chance to fire.
Consider this snippet:
```haskell
data T = MkT { foo :: Int }
{-# INLINE[1] foo #-}
```
currently ghc doesn't allow us to specify pragmas for the field selector.
```
A.hs:15:15: error:
The INLINE pragma for `foo' lacks an accompanying binding
(The INLINE pragma must be given where `foo' is declared)
|
15 | {-# INLINE[1] foo #-}
```
## Proposal
In core we treat field selectors just like regular bindings. They generate code, are inlined, get unfoldings and so on.
So we should also allow users to reference them in pragmas just like regular bindings.
The frontend is not something I'm very familiar with so this might be tricky in practice depending on when we actually generate the selector bindings. But it seems like a reasonable request.Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/18056Float out prevents RULES from firing.2020-04-17T22:26:23ZAndreas KlebingerFloat out prevents RULES from firing.## Motivation
Consider this function and rule:
```haskell
foo :: Int -> Bool
foo x = L.elem x [1,2::Int]
{-# RULES
"elem/build" [2] forall x (g :: forall b . (Int -> b -> b) -> b -> b)
. L.elem x (build g) = g (\ y r -> (x == y) ||...## Motivation
Consider this function and rule:
```haskell
foo :: Int -> Bool
foo x = L.elem x [1,2::Int]
{-# RULES
"elem/build" [2] forall x (g :: forall b . (Int -> b -> b) -> b -> b)
. L.elem x (build g) = g (\ y r -> (x == y) || r) False
#-}
```
If compiled with -O -fno-full-laziness this fires as expected and produces:
```
foo
= \ (x_ay4 :: Int) ->
case x_ay4 of { I# x1_a1rE ->
case x1_a1rE of {
__DEFAULT -> GHC.Types.False;
1# -> GHC.Types.True;
2# -> GHC.Types.True
}
}
```
which is what we want.
If we compile using -O we get after FloatOut during the InitialPhase:
```
lvl_s1vK :: forall b. (Int -> b -> b) -> b -> b
lvl_s1vK
= \ f xs ->
f 1 (f 2 xs)
list :: [Int]
list = build lvl_s1vK
foo :: Int -> Bool
foo = \ x -> L.elem x list
```
However we never match on `L.elem x list` even though it would match the rule if the referenced bindings where inlined.
## Proposal
I'm not sure how this would be best addressed.Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/15543Binary crashes under dtrace2022-10-03T13:41:34ZLast GBinary crashes under dtraceWhen I'm trying to attach to the simple binary with DTrace command (`sudo dtrace -n 'pid$1:::' `ps aux | grep FibbSlow | grep -v grep | awk '{print $2}'` `) it crashes with various outcomes. This happens on both GHC 8.4.3 from `stack` an...When I'm trying to attach to the simple binary with DTrace command (`sudo dtrace -n 'pid$1:::' `ps aux | grep FibbSlow | grep -v grep | awk '{print $2}'` `) it crashes with various outcomes. This happens on both GHC 8.4.3 from `stack` and manually built ghc from the master branch.
Crashes:
```
lastg-mbp:t lastg$ ./FibbSlow.master 55
FibbSlow.master: internal error: scavenge: unimplemented/strange closure type 13369548 @ 0x420021abb0^[[B
(GHC version 8.7.20180817 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
```
lastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55
FibbSlow.stack.8.4: internal error: scavenge_one: strange object 13369548
(GHC version 8.4.3 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap: 6
```
```
lastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55
FibbSlow.stack.8.4: internal error: scavenge_one: strange object 13369548
(GHC version 8.4.3 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap: 6
```
```
lastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55
Segmentation fault: 11
```
Source code for the binary:
https://gist.github.com/last-g/cfddab60a8520eb51214ef2a7bc48ec2
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Binary crashes under dtrace","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"Research needed","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["crash","dtrace,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I'm trying to attach to the simple binary with DTrace command ({{{sudo dtrace -n 'pid$1:::' `ps aux | grep FibbSlow | grep -v grep | awk '{print $2}'` }}}) it crashes with various outcomes. This happens on both GHC 8.4.3 from `stack` and manually built ghc from the master branch.\r\n\r\nCrashes:\r\n\r\n{{{\r\nlastg-mbp:t lastg$ ./FibbSlow.master 55\r\nFibbSlow.master: internal error: scavenge: unimplemented/strange closure type 13369548 @ 0x420021abb0^[[B\r\n (GHC version 8.7.20180817 for x86_64_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\n{{{\r\nlastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55\r\nFibbSlow.stack.8.4: internal error: scavenge_one: strange object 13369548\r\n (GHC version 8.4.3 for x86_64_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort trap: 6\r\n}}}\r\n\r\n{{{\r\nlastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55\r\nFibbSlow.stack.8.4: internal error: scavenge_one: strange object 13369548\r\n (GHC version 8.4.3 for x86_64_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort trap: 6\r\n}}}\r\n\r\n{{{\r\nlastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55\r\nSegmentation fault: 11\r\n}}}\r\n\r\nSource code for the binary:\r\nhttps://gist.github.com/last-g/cfddab60a8520eb51214ef2a7bc48ec2","type_of_failure":"OtherFailure","blocking":[]} -->Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/13149Giving Backpack a Promotion2019-11-27T16:57:26ZEdward Z. YangGiving Backpack a PromotionThis ticket is tracking assumptions the current implementation of Backpack makes about terms and types, which may be violated when more and more term-level things start being lifted into the type level. I don't expect any work to be done...This ticket is tracking assumptions the current implementation of Backpack makes about terms and types, which may be violated when more and more term-level things start being lifted into the type level. I don't expect any work to be done on this in the near future, but I'd like to keep track of these breadcrumbs.
- We currently assume that it is impossible for a typechecked-only module (that is, one with no Core unfoldings) to refer to a DFun or a coercion axiom. In the absence of promotion, I'm pretty sure this is the case, since there is no way to refer to a term from a type (DFun), and coercions do not ordinarily occur at the type level.
With promotion, this is not true:
```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE Rank2Types #-}
{-# LANGUAGE TypeInType #-}
unit p where
signature A where
import GHC.Types
type family F a where
F Bool = Type
module B where
import A
foo :: forall (a :: F Bool). a -> a
foo x = x
unit q where
dependency p[A=<A>]
module C where
import B
```
> This will fail in a puzzling way:
```
<no location info>: error:
The identifier D:R:F does not exist in the signature for <A>
(Try adding it to the export list in that hsig file.)
```
- (Put more problems here)Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/11528Representation of value set abstractions as trees causes performance issues2020-07-08T09:06:43ZGeorgios KarachaliasRepresentation of value set abstractions as trees causes performance issuesThe new exhaustiveness checker has been originally designed to use a prefix tree representation of value set abstractions. Unfortunately, this resulted in huge performance problems (see for example #11160, #11161, #11162, #11163, #11195,...The new exhaustiveness checker has been originally designed to use a prefix tree representation of value set abstractions. Unfortunately, this resulted in huge performance problems (see for example #11160, #11161, #11162, #11163, #11195, #11276, #11303, #11374, #11302) and we had to switch to a representation of value set abstractions as a list of value vector abstractions.
It would be nice to switch back to the prefix tree representation but the performance problems with it are yet to be characterized so I have created a branch using this representation (`wip/gadtpm-prefix-tree`) to further investigate this approach.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Representation of value set abstractions as trees causes performance issues","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"Research needed","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"gkaracha"},"version":"","keywords":["PatternMatchWarnings"],"differentials":[],"test_case":"","architecture":"","cc":["simonpj"],"type":"Task","description":"The new exhaustiveness checker has been originally designed to use a prefix tree representation of value set abstractions. Unfortunately, this resulted in huge performance problems (see for example #11160, #11161, #11162, #11163, #11195, #11276, #11303, #11374, #11302) and we had to switch to a representation of value set abstractions as a list of value vector abstractions.\r\n\r\nIt would be nice to switch back to the prefix tree representation but the performance problems with it are yet to be characterized so I have created a branch using this representation (`wip/gadtpm-prefix-tree`) to further investigate this approach.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Research needed