GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-11-18T17:56:42Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/5059Pragma to SPECIALISE on value arguments2021-11-18T17:56:42ZbatterseapowerPragma to SPECIALISE on value argumentsI've sometimes found myself wishing for this pragma to get some "partial evaluation on the cheap". The idea is to allow something like:
```
defaultOpts :: Options
defaultOpts = ...
{-# SPECIALISE f defaultOpts :: Int -> Int #-}
f :: Op...I've sometimes found myself wishing for this pragma to get some "partial evaluation on the cheap". The idea is to allow something like:
```
defaultOpts :: Options
defaultOpts = ...
{-# SPECIALISE f defaultOpts :: Int -> Int #-}
f :: Options -> Int -> Int
f opts x = ... f opts ...
```
This would desugar into this additional code:
```
{-# RULES "f/spec" f defaultOpts = f_spec_1 #-}
f_spec_1 = (\opts x -> ... ... f opts ...) defaultOpts -- NB: body of f duplicated
```
The hope is that the simplifier and RULE matcher will tidy this up so we get a nice loop back to f_spec_1 with the body of the function specialised for the particular opts.
This is useful when functions are called often with particular arguments. An example would be where "f" is an edit-distance function which takes costs to be assigned to each edit, strings to be compared and returns an integer distance. In my library, the costs are given almost always going to be the default ones so I want to make that case fast, but I want to allow the user to supply their own set.
This pragma is somewhat subsumed by:
1. SpecConstr, if the options are algebraic data/literals that are also scrutinised by the body of f
1. Static argument transformation, except that the RULE based strategy achieves more code sharing compared to SAT
I think that pragma might be a relatively simple to implement nice-to-have feature.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Pragma to SPECIALISE on value arguments","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I've sometimes found myself wishing for this pragma to get some \"partial evaluation on the cheap\". The idea is to allow something like:\r\n\r\n{{{\r\ndefaultOpts :: Options\r\ndefaultOpts = ...\r\n\r\n{-# SPECIALISE f defaultOpts :: Int -> Int #-}\r\nf :: Options -> Int -> Int\r\nf opts x = ... f opts ...\r\n}}}\r\n\r\nThis would desugar into this additional code:\r\n\r\n{{{\r\n{-# RULES \"f/spec\" f defaultOpts = f_spec_1 #-}\r\nf_spec_1 = (\\opts x -> ... ... f opts ...) defaultOpts -- NB: body of f duplicated\r\n}}}\r\n\r\nThe hope is that the simplifier and RULE matcher will tidy this up so we get a nice loop back to f_spec_1 with the body of the function specialised for the particular opts.\r\n\r\nThis is useful when functions are called often with particular arguments. An example would be where \"f\" is an edit-distance function which takes costs to be assigned to each edit, strings to be compared and returns an integer distance. In my library, the costs are given almost always going to be the default ones so I want to make that case fast, but I want to allow the user to supply their own set.\r\n\r\nThis pragma is somewhat subsumed by:\r\n\r\n 1. SpecConstr, if the options are algebraic data/literals that are also scrutinised by the body of f\r\n\r\n 2. Static argument transformation, except that the RULE based strategy achieves more code sharing compared to SAT\r\n\r\nI think that pragma might be a relatively simple to implement nice-to-have feature.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/5016Make Template Haskell: -ddump-splices generate executable code2019-07-07T18:57:19ZguestMake Template Haskell: -ddump-splices generate executable codehttp://hpaste.org/44711/testsunpackedhs
I am Aur Saraf, reachable sonoflilit @ don't-be-evil.
I wanted to edit some code that was autogenerated by TH with Michael Snoyman's Persistent library (version 0.3.1.3).
So I ran it through ghc...http://hpaste.org/44711/testsunpackedhs
I am Aur Saraf, reachable sonoflilit @ don't-be-evil.
I wanted to edit some code that was autogenerated by TH with Michael Snoyman's Persistent library (version 0.3.1.3).
So I ran it through ghc --make -ddump-splices 2\>&1 \| less, and in a copy of my original file replaced the TH with the splices.
It wouldn't compile, so I googled like crazy and eventually asked for help on \#haskell, where the kindly kmc helped me get it to compile.
We identified several inaccuracies in the pretty printer.
I had to do a few things, among them:
- Delete some instances of the keyword "instance":
```
02:12 < kmc> oh, i think the problem is simply that you don't use the kw "instance" for associated types
02:12 < kmc> only for standalone family instances
02:12 < kmc> sorry i didn't remember that earlier
02:13 < kmc> so ghc / TH is being imprecise with how it outputs generated asstype instances
[..]
02:14 < kmc> well splices generate abstract syntax trees
02:15 < kmc> and i guess the AST for a family instance inside or outside a class instance is the same
02:15 < kmc> but the concrete syntax differs
02:15 < kmc> and the pretty-printer for that AST is not taking that into account
```
- Change many illegal identifiers:
```
01:51 < kmc> sonoflilit, it looks like TH is generating names of the form x[a2ur]
01:51 < kmc> which aren't valid Haskell identifiers
01:52 < kmc> i don't know if that's related to your problem
01:52 < kmc> but it seems to be a reason why this dumped splice won't work as-is
```
- Remove {}s:
```
02:23 < sonoflilit> { entityDef _ = Database.Persist.Base.EntityDef
02:24 < sonoflilit> TestsUnpacked.hs:47:4: parse error on input `{'
02:25 < kmc> oh i think "entityDef _ = ..." starts off the methods part of the type class instance
02:25 < kmc> so that brace should move to right after "instance PersistEntity Person where"
02:25 < kmc> or probably, not exist
```
> (also, in other parts of the file)
- Fix empty data declarations:
```
02:24 < kmc> at line 137-139 you have three "data instance"s with no right-hand side
02:26 < kmc> does "data Foo =" actually work
02:26 < kmc> as an alternative to "data Foo"
02:27 < sonoflilit> hmm, tested, no
02:27 < sonoflilit> and you need a special extension to allow "data Foo"
```
> (I needed to `{-# LANGUAGE EmptyDataDecls #-}`, as well as remove the "=" from the lines)
- Change some wacky syntax:
```
02:33 < sonoflilit> kmc: what's wrong with my line 192's ->?
02:33 < sonoflilit> It gives an error after I solved all the { errors
02:36 < kmc> sonoflilit, not sure... try rewriting that pattern as ((x_a3pU,_):_)
02:37 < kmc> that use of qualified infix *should* work
02:37 < kmc> also it keeps using { } to override layout but then not inserting ;
02:39 < kmc> oh "GHC.Types.[]"
02:39 < kmc> probably isn't right
02:40 < kmc> unqualify that mo'fo'
```
- Add all sorts of imports:
```
TestsUnpacked.hs:21:19:
Not in scope: type constructor or class `GHC.Int.Int64'
TestsUnpacked.hs:31:18:
Not in scope:
type constructor or class `Web.Routes.Quasi.Classes.SinglePiece'
[..]
TestsUnpacked.hs:186:20:
Not in scope: data constructor `Database.Persist.Base.SqlString'
TestsUnpacked.hs:187:26:
Not in scope:
data constructor `Database.Persist.Base.PersistString'
```
- Copy code from a library because it was private:
```
TestsUnpacked.hs:67:29: Not in scope: `Database.Persist.TH.apE'
```
- Add parentheses to type constructor definitions:
```
TestsUnpacked.hs:40:24:
`Maybe' is not applied to enough type arguments
PersonColorEq Maybe String |
becomes
PersonColorEq (Maybe String) |
```
- Eventually I gave up at:
```
TestsUnpacked.hs:61:4:
The equation(s) for `toPersistFields' have four arguments,
but its type `Person -> [SomePersistField]' has only one
In the instance declaration for `PersistEntity Person'
TestsUnpacked.hs:87:4:
The equation(s) for `persistUpdateToValue' have two arguments,
but its type `Update Person -> PersistValue' has only one
In the instance declaration for `PersistEntity Person'
```
What I'd recommend the person who takes this bug is to follow my steps to reproduce and then again and again until the file compiles with as few manual changes as possible (perhaps the added language extension and imports are unavoidable, all else is clearly a bug).8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4980Warning about module abbreviation clashes2019-07-07T18:57:29ZLemmingWarning about module abbreviation clashesPlease add the option -fwarn-module-rename-collision that makes GHC to do the following: If GHC encounters an import situation like
```
module Main where
import qualified Data.A as A
import qualified Control.A as A
```
then GHC should...Please add the option -fwarn-module-rename-collision that makes GHC to do the following: If GHC encounters an import situation like
```
module Main where
import qualified Data.A as A
import qualified Control.A as A
```
then GHC should emit a warning like
```
Main.hs:3:0:
Main.hs:4:0:
Warning: Both Data.A and Control.A are renamed to A.
An identifier like A.ident can only be resolved,
if it is either in Data.A or Control.A.
Better rename both modules to different names.
```
Reason for this warning is, that if 'ident' is from Data.A as of writing Main, and later another variable named 'ident' is added to Control.A, then A.ident can no longer be resolved in Main. That is, by accidental module rename collisions even qualified imports carry the risk of future name collisions.
Related to #4977
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------- |
| Version | 7.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ghc@henning-thielemann.de |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Warning about module abbreviation clashes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ghc@henning-thielemann.de"],"type":"FeatureRequest","description":"Please add the option -fwarn-module-rename-collision that makes GHC to do the following: If GHC encounters an import situation like\r\n{{{\r\nmodule Main where\r\n\r\nimport qualified Data.A as A\r\nimport qualified Control.A as A\r\n}}}\r\nthen GHC should emit a warning like\r\n{{{\r\nMain.hs:3:0:\r\nMain.hs:4:0:\r\n Warning: Both Data.A and Control.A are renamed to A.\r\n An identifier like A.ident can only be resolved,\r\n if it is either in Data.A or Control.A.\r\n Better rename both modules to different names.\r\n}}}\r\n\r\nReason for this warning is, that if 'ident' is from Data.A as of writing Main, and later another variable named 'ident' is added to Control.A, then A.ident can no longer be resolved in Main. That is, by accidental module rename collisions even qualified imports carry the risk of future name collisions.\r\n\r\nRelated to #4977\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4959Warning about variables with leading underscore that are used anyway2019-07-07T18:57:37ZLemmingWarning about variables with leading underscore that are used anywayI use -Wall all the time, which includes -fwarn-unused-binds and -fwarn-unused-matches that warn about variable bindings that are not used. It already spotted lots of mistakes for me. You can suppress the warning by prepending an undersc...I use -Wall all the time, which includes -fwarn-unused-binds and -fwarn-unused-matches that warn about variable bindings that are not used. It already spotted lots of mistakes for me. You can suppress the warning by prepending an underscore '_' to a variable name. However, I have recently seen code, where variable names with leading underscores are regularly used, where other programmers might have chosen trailing underscores or primes. I suspect that the programmer was not aware, that he disabled warnings about unused bindings this way. Thus I like to have a warning about underscored variables that are used in the sense of the definition given for -fwarn-unused-binds in http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html.
We still have to decide whether this warning should be part of -Wall or -fwarn-unused-binds or whether there should be a separate option like -fwarn-used-underscored-binds.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------- |
| Version | 7.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ghc@henning-thielemann.de |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Warning about variables with leading underscore that are used anyway","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":["underscore","unused","variable","warning"],"differentials":[],"test_case":"","architecture":"","cc":["ghc@henning-thielemann.de"],"type":"FeatureRequest","description":"I use -Wall all the time, which includes -fwarn-unused-binds and -fwarn-unused-matches that warn about variable bindings that are not used. It already spotted lots of mistakes for me. You can suppress the warning by prepending an underscore '_' to a variable name. However, I have recently seen code, where variable names with leading underscores are regularly used, where other programmers might have chosen trailing underscores or primes. I suspect that the programmer was not aware, that he disabled warnings about unused bindings this way. Thus I like to have a warning about underscored variables that are used in the sense of the definition given for -fwarn-unused-binds in http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html.\r\nWe still have to decide whether this warning should be part of -Wall or -fwarn-unused-binds or whether there should be a separate option like -fwarn-used-underscored-binds.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4913Make event tracing conditional on an RTS flag only2019-07-07T18:57:57ZtibbeMake event tracing conditional on an RTS flag onlyThe current event tracing mechanism is enabled at link time by linking in one of two different versions of a C function, one being a no-op function. We could allow users to enable/disable tracing using a RTS flag instead, making event lo...The current event tracing mechanism is enabled at link time by linking in one of two different versions of a C function, one being a no-op function. We could allow users to enable/disable tracing using a RTS flag instead, making event logging more convenient to use. At the same time we would introduce tracing levels.
Design:
Add a static memory location where the current tracing level is stored:
```
uint tracelevel = 0;
```
Modify `GHC.Exts.traceEvent` to read
```
foreign import ccall unsafe "&tracelevel" :: Ptr Word
traceEvent :: String -> IO ()
traceEvent msg =
if unsafePerformIO (peek tracelevel) > 0
then do
withCString msg $ \(Ptr p) -> IO $ \s ->
case traceEvent# p s of s' -> (# s', () #)
else return ()
```
and (optionally) add some more functions that log at different trace levels.
This should be no slower than the current system. With inlining this should result in a load and a branch at the call site. The load should be cheap as the value is likely to be in cache (as it never changes). The branch should be easy to predict as it's always the same. With some cooperation from the code generator we could make sure that the branch is always cheap.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make event tracing conditional on an RTS flag only","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The current event tracing mechanism is enabled at link time by linking in one of two different versions of a C function, one being a no-op function. We could allow users to enable/disable tracing using a RTS flag instead, making event logging more convenient to use. At the same time we would introduce tracing levels.\r\n\r\nDesign:\r\n\r\nAdd a static memory location where the current tracing level is stored:\r\n\r\n{{{\r\nuint tracelevel = 0;\r\n}}}\r\n\r\nModify `GHC.Exts.traceEvent` to read\r\n\r\n{{{\r\nforeign import ccall unsafe \"&tracelevel\" :: Ptr Word\r\n\r\ntraceEvent :: String -> IO ()\r\ntraceEvent msg =\r\n if unsafePerformIO (peek tracelevel) > 0\r\n then do\r\n withCString msg $ \\(Ptr p) -> IO $ \\s ->\r\n case traceEvent# p s of s' -> (# s', () #)\r\n else return ()\r\n}}}\r\n\r\nand (optionally) add some more functions that log at different trace levels.\r\n\r\nThis should be no slower than the current system. With inlining this should result in a load and a branch at the call site. The load should be cheap as the value is likely to be in cache (as it never changes). The branch should be easy to predict as it's always the same. With some cooperation from the code generator we could make sure that the branch is always cheap.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4823Loop strength reduction for array indexing2019-07-07T18:58:23ZtibbeLoop strength reduction for array indexingIndexing into a `ByteArray#` in a loop is currently more expensive than working on a `ForeignPtr` due to lack of strength reduction. Pointer arithmetic is cheaper than using base + offset indexing. We could convert indexing into pointer ...Indexing into a `ByteArray#` in a loop is currently more expensive than working on a `ForeignPtr` due to lack of strength reduction. Pointer arithmetic is cheaper than using base + offset indexing. We could convert indexing into pointer arithmetic if it weren't for the GC being able to move objects around.
Tom Rodriguez had the following to say about Java HotSpot and loop strength reduction:
> "The server compiler doesn't do explicit loop strength reduction though it can get a bit of it as a result of other transformations loop invariant code motion. I've played a bit with doing it more explicitly but had some difficulty getting benefit from it. The resulting pointers are handled by the notion of derived pointers. These are interior pointers that are tracked along with their base pointers. At the beginning of GC the offset from the base of the derived pointer is saved and the pointer is converted to the base and after GC the offset is added back in. That part all happens automatically. Searching for DerivedPointer will lead you to the relevant code."
Perhaps it's an idea we could try?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Loop strength reduction for array indexing","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Indexing into a `ByteArray#` in a loop is currently more expensive than working on a `ForeignPtr` due to lack of strength reduction. Pointer arithmetic is cheaper than using base + offset indexing. We could convert indexing into pointer arithmetic if it weren't for the GC being able to move objects around.\r\n\r\nTom Rodriguez had the following to say about Java HotSpot and loop strength reduction:\r\n\r\n> \"The server compiler doesn't do explicit loop strength reduction though it can get a bit of it as a result of other transformations loop invariant code motion. I've played a bit with doing it more explicitly but had some difficulty getting benefit from it. The resulting pointers are handled by the notion of derived pointers. These are interior pointers that are tracked along with their base pointers. At the beginning of GC the offset from the base of the derived pointer is saved and the pointer is converted to the base and after GC the offset is added back in. That part all happens automatically. Searching for DerivedPointer will lead you to the relevant code.\"\r\n\r\nPerhaps it's an idea we could try?","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4815Instance constraints should be used when deriving on associated data types2019-07-07T18:58:25ZbatterseapowerInstance constraints should be used when deriving on associated data typesConsider this program:
```
{-# LANGUAGE TypeFamilies, FlexibleContexts #-}
class Eq (Associated a) => Foo a where
data Associated a
instance Foo a => Foo (Maybe a) where
data Associated (Maybe a) = AssociatedMaybe (Associated ...Consider this program:
```
{-# LANGUAGE TypeFamilies, FlexibleContexts #-}
class Eq (Associated a) => Foo a where
data Associated a
instance Foo a => Foo (Maybe a) where
data Associated (Maybe a) = AssociatedMaybe (Associated a)
deriving (Eq)
```
This does not compile, giving this error message:
```
/Users/mbolingbroke/Junk/Repro.hs:9:40:
No instance for (Eq (Associated a))
arising from the 'deriving' clause of a data type declaration
at /Users/mbolingbroke/Junk/Repro.hs:9:40-41
Possible fix:
add an instance declaration for (Eq (Associated a))
or use a standalone 'deriving instance' declaration instead,
so you can specify the instance context yourself
When deriving the instance for (Eq (Associated (Maybe a)))
```
However, this is surprising because I clearly state that a is Foo, and hence (Associated a) has an Eq instance by the superclass constraint on Foo.
If I point this out explicitly using standalone deriving it works:
```
{-# LANGUAGE TypeFamilies, FlexibleContexts #-}
{-# LANGUAGE StandaloneDeriving, FlexibleInstances #-}
class Eq (Associated a) => Foo a where
data Associated a
instance Foo a => Foo (Maybe a) where
data Associated (Maybe a) = AssociatedMaybe (Associated a)
-- deriving (Eq)
deriving instance Foo a => Eq (Associated (Maybe a))
```
So I think the default behaviour for "deriving" on an associated data family should be to include the constraints from the enclosing instance. For now the workaround is just to use standalone deriving.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Instance constraints should be used when deriving on associated data types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Consider this program:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies, FlexibleContexts #-}\r\n\r\nclass Eq (Associated a) => Foo a where\r\n data Associated a\r\n\r\ninstance Foo a => Foo (Maybe a) where\r\n data Associated (Maybe a) = AssociatedMaybe (Associated a)\r\n deriving (Eq)\r\n}}}\r\n\r\nThis does not compile, giving this error message:\r\n\r\n{{{\r\n\r\n/Users/mbolingbroke/Junk/Repro.hs:9:40:\r\n No instance for (Eq (Associated a))\r\n arising from the 'deriving' clause of a data type declaration\r\n at /Users/mbolingbroke/Junk/Repro.hs:9:40-41\r\n Possible fix:\r\n add an instance declaration for (Eq (Associated a))\r\n or use a standalone 'deriving instance' declaration instead,\r\n so you can specify the instance context yourself\r\n When deriving the instance for (Eq (Associated (Maybe a)))\r\n}}}\r\n\r\nHowever, this is surprising because I clearly state that a is Foo, and hence (Associated a) has an Eq instance by the superclass constraint on Foo.\r\n\r\nIf I point this out explicitly using standalone deriving it works:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies, FlexibleContexts #-}\r\n{-# LANGUAGE StandaloneDeriving, FlexibleInstances #-}\r\n\r\nclass Eq (Associated a) => Foo a where\r\n data Associated a\r\n\r\ninstance Foo a => Foo (Maybe a) where\r\n data Associated (Maybe a) = AssociatedMaybe (Associated a)\r\n-- deriving (Eq)\r\n\r\nderiving instance Foo a => Eq (Associated (Maybe a))\r\n}}}\r\n\r\nSo I think the default behaviour for \"deriving\" on an associated data family should be to include the constraints from the enclosing instance. For now the workaround is just to use standalone deriving.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4520startup code on Windows should use SetDllDirectory("")2019-07-07T18:58:37Zduncanstartup code on Windows should use SetDllDirectory("")See [Raymond's blog](http://blogs.msdn.com/b/oldnewthing/archive/2010/11/10/10088566.aspx) about (un)safe dll loading. He points to a [support article](http://support.microsoft.com/kb/2389418) which recommends that new programs use `SetD...See [Raymond's blog](http://blogs.msdn.com/b/oldnewthing/archive/2010/11/10/10088566.aspx) about (un)safe dll loading. He points to a [support article](http://support.microsoft.com/kb/2389418) which recommends that new programs use `SetDllDirectory("")` to prevent the problem (it's not the default because that'd break old programs).
In the GHC context, this could go in the startup code for standalone executables. It is a process-scope property so changing it is not appropriate for DLL startup.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"startup code on Windows should use SetDllDirectory(\"\")","status":"New","operating_system":"Unknown/Multiple","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"See [http://blogs.msdn.com/b/oldnewthing/archive/2010/11/10/10088566.aspx Raymond's blog] about (un)safe dll loading. He points to a [http://support.microsoft.com/kb/2389418 support article] which recommends that new programs use `SetDllDirectory(\"\")` to prevent the problem (it's not the default because that'd break old programs).\r\n\r\nIn the GHC context, this could go in the startup code for standalone executables. It is a process-scope property so changing it is not appropriate for DLL startup.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4479Implement TDNR2021-01-08T20:29:07ZgidynImplement TDNRA request to implement [TDNR](https://wiki.haskell.org/TypeDirectedNameResolution).A request to implement [TDNR](https://wiki.haskell.org/TypeDirectedNameResolution).8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4466Add extension for type application2019-07-07T18:58:52ZIan Lynagh <igloo@earth.li>Add extension for type applicationIn
http://www.haskell.org/pipermail/libraries/2010-October/014761.html
we discussed adding an extension for explicit type application.
The main stumbling block is syntax.
For example, we would like to be able to write something to the ...In
http://www.haskell.org/pipermail/libraries/2010-October/014761.html
we discussed adding an extension for explicit type application.
The main stumbling block is syntax.
For example, we would like to be able to write something to the effect of
```
(Just @ Char) 'a'
```
and also to be able to pattern match types, e.g.
```
f ((Just @ t) x) = (Right @ String @ t) x
```
For a more useful example:
```
data T where
MkT :: forall a. a -> (a -> Int) -> T
f (MkT @ a x g) = g (x::a)
```
Possible suggested syntaxes to make something of type
```
Maybe (forall a. a->a)
```
were:
```
Just @ (forall a. a->a) id (@ has another meaning in patterns)
Just[forall a. a->a] id (pvs, opal, HasCASL with paramterized modules; conflicts with Haskell list syntax)
Just {forall a. a->a} id (Agda)
#Just (forall a. a->a) id
@Just (forall a. a->a) id (coq)
```
In the last 2 cases we would presumably have something like
```
Just :: forall a . a -> Maybe a
Just :: Char -> Maybe Char
#Just :: /\ a . a -> Maybe a
#Just Char :: Char -> Maybe Char
```
and similarly
```
#map :: /\ a b . (a -> b) -> [a] -> [b]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add extension for type application","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"\r\nIn\r\nhttp://www.haskell.org/pipermail/libraries/2010-October/014761.html\r\nwe discussed adding an extension for explicit type application.\r\n\r\nThe main stumbling block is syntax.\r\n\r\nFor example, we would like to be able to write something to the effect of\r\n{{{\r\n(Just @ Char) 'a'\r\n}}}\r\nand also to be able to pattern match types, e.g.\r\n{{{\r\nf ((Just @ t) x) = (Right @ String @ t) x\r\n}}}\r\n\r\nFor a more useful example:\r\n{{{\r\ndata T where\r\n MkT :: forall a. a -> (a -> Int) -> T\r\n\r\nf (MkT @ a x g) = g (x::a)\r\n}}}\r\n\r\nPossible suggested syntaxes to make something of type\r\n{{{\r\nMaybe (forall a. a->a)\r\n}}}\r\nwere:\r\n{{{\r\nJust @ (forall a. a->a) id (@ has another meaning in patterns)\r\nJust[forall a. a->a] id (pvs, opal, HasCASL with paramterized modules; conflicts with Haskell list syntax)\r\nJust {forall a. a->a} id (Agda)\r\n#Just (forall a. a->a) id\r\n@Just (forall a. a->a) id (coq)\r\n}}}\r\n\r\nIn the last 2 cases we would presumably have something like\r\n{{{\r\nJust :: forall a . a -> Maybe a\r\nJust :: Char -> Maybe Char\r\n#Just :: /\\ a . a -> Maybe a\r\n#Just Char :: Char -> Maybe Char\r\n}}}\r\nand similarly\r\n{{{\r\n#map :: /\\ a b . (a -> b) -> [a] -> [b]\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4459Polymorphic Data.Dynamic2019-07-07T18:58:54ZvivianPolymorphic Data.DynamicAt some point in the compilation process an expression acquires a fully-specified, possibly polymorphic, type. If we add an operation that join that type and that expresssion, say `TypedAny`, then we can implement the part of #4316 reque...At some point in the compilation process an expression acquires a fully-specified, possibly polymorphic, type. If we add an operation that join that type and that expresssion, say `TypedAny`, then we can implement the part of #4316 requested by mitar.
In GHCi we can evaluate `HValue`s **and also** string them together with `bind` statements.
The function
```
applyDynamic :: TypedAny -> TypedAny -> Maybe TypedAny
```
includes in its implementation a dictionary lookup and possible dynamic object linking for class methods.
the function
```
fromDynamic :: TypedAny -> Maybe a
```
like `applyDynamic`, runs the typechecker at runtime to unify (and possibly link) the dynamic type (!TypedAny) and the static type (a).
*Conjecture * Since we already have `typecase` (classes), with type families, this feature provides/simulates dependent types.8.0.1vivianvivianhttps://gitlab.haskell.org/ghc/ghc/-/issues/4453Allow specifying .hi files of imports on command line in batch mode2019-07-07T18:58:55ZduncanAllow specifying .hi files of imports on command line in batch modeIt is useful for a build agent (e.g. cabal, or makefile) to have full control over the search path. Reasons you might want to do this are below.
The way a build agent can do this is to instruct ghc not to do any searching at all, using ...It is useful for a build agent (e.g. cabal, or makefile) to have full control over the search path. Reasons you might want to do this are below.
The way a build agent can do this is to instruct ghc not to do any searching at all, using the flag `-i` which sets the search path to empty. Then the build agent has to supply ghc with all the `.hs` files that are needed, e.g.:
```
ghc --make -i Foo.hs Bar.hs
```
(any imports outside of these modules, or the package modules will fail)
This no-search scheme works in `--make` mode but not in batch mode. For that we need to be able to say:
```
ghc -i -c Foo.hs
ghc -i -c Bar.hs Foo.hi
```
That is, we need to be able to specify the .hi files of imported modules on the command line.
A build agent may want to do this so that it is insulated from the particular choices of ghc's search path semantics and/or have different choices. For example, ghc prefers modules in local .hs/.hi files to package modules while the build agent may want the reverse in some circumstances.
Apart from search path policy, it makes sense for a build agent to take this approach simply for correctness and simplicity. A correct build agent must track dependencies absolutely precisely, so it has to know which specific .hi files ghc will pick anyway. It is simpler for the build agent to tell ghc those .hi files rather than trying to precisely arrange things to match ghc's search behaviour.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow specifying .hi files of imports on command line in batch mode","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It is useful for a build agent (e.g. cabal, or makefile) to have full control over the search path. Reasons you might want to do this are below.\r\n\r\nThe way a build agent can do this is to instruct ghc not to do any searching at all, using the flag `-i` which sets the search path to empty. Then the build agent has to supply ghc with all the `.hs` files that are needed, e.g.:\r\n{{{\r\nghc --make -i Foo.hs Bar.hs\r\n}}}\r\n(any imports outside of these modules, or the package modules will fail)\r\n\r\nThis no-search scheme works in `--make` mode but not in batch mode. For that we need to be able to say:\r\n{{{\r\nghc -i -c Foo.hs\r\nghc -i -c Bar.hs Foo.hi\r\n}}}\r\nThat is, we need to be able to specify the .hi files of imported modules on the command line.\r\n\r\nA build agent may want to do this so that it is insulated from the particular choices of ghc's search path semantics and/or have different choices. For example, ghc prefers modules in local .hs/.hi files to package modules while the build agent may want the reverse in some circumstances.\r\n\r\nApart from search path policy, it makes sense for a build agent to take this approach simply for correctness and simplicity. A correct build agent must track dependencies absolutely precisely, so it has to know which specific .hi files ghc will pick anyway. It is simpler for the build agent to tell ghc those .hi files rather than trying to precisely arrange things to match ghc's search behaviour.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4442Add unaligned version of indexWordArray#2022-01-27T14:21:19ZtibbeAdd unaligned version of indexWordArray#`indexWordArray#` takes an offset in whole words, making it impossible to do unaligned reads on platforms that support such reads. This has performance implications for some programs e.g. implementations of !MurmurHash.
I propose we add...`indexWordArray#` takes an offset in whole words, making it impossible to do unaligned reads on platforms that support such reads. This has performance implications for some programs e.g. implementations of !MurmurHash.
I propose we add versions of `indexWord*Array` that take byte offsets. The user is responsible for only using those on platforms that support them and the implementation is free to crash if they're used elsewhere.8.0.1reinerpreinerphttps://gitlab.haskell.org/ghc/ghc/-/issues/4340Add alignment to hsc2hs template2019-07-07T18:59:27ZmitarAdd alignment to hsc2hs templateI think [commonly used](http://www.haskell.org/haskellwiki/FFICookBook#Working_with_structs):
```
#let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__); }, y__)
```
should be added to official hsc2hs template. Wha...I think [commonly used](http://www.haskell.org/haskellwiki/FFICookBook#Working_with_structs):
```
#let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__); }, y__)
```
should be added to official hsc2hs template. What are cons to that?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.12.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mmitar@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add alignment to hsc2hs template","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mmitar@gmail.com"],"type":"FeatureRequest","description":"I think [http://www.haskell.org/haskellwiki/FFICookBook#Working_with_structs commonly used]:\r\n\r\n{{{\r\n#let alignment t = \"%lu\", (unsigned long)offsetof(struct {char x__; t (y__); }, y__)\r\n}}}\r\n\r\nshould be added to official hsc2hs template. What are cons to that?","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/4329GHC.Conc modifyTVar primitive2019-07-07T18:59:30ZdmbarbourGHC.Conc modifyTVar primitiveI would like modifyTVar as a 'write-only' primitive supported by GHC's STM.
The semantic definition is:
> modifyTVar :: TVar a -\> (a -\> a) -\> STM ()
> modifyTVar v f = readTVar v \>\>= writeTVar v . f
However, explicitly reading th...I would like modifyTVar as a 'write-only' primitive supported by GHC's STM.
The semantic definition is:
> modifyTVar :: TVar a -\> (a -\> a) -\> STM ()
> modifyTVar v f = readTVar v \>\>= writeTVar v . f
However, explicitly reading then writing the TVar introduces unnecessary interference between transactions. The value held by the TVar does not affect the behavior of the transaction. modifyTVar should not interfere with other transactions that only writeTVar or modifyTVar.
Even if a non-interfering implementation isn't feasible due to the underlying implementation of GHC's STM, providing the function would provide a point for a transparent upgrade in the future.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.Conc modifyTVar primitive","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":["Concurrency","STM,","TVar,","modifyTVar,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I would like modifyTVar as a 'write-only' primitive supported by GHC's STM.\r\n\r\nThe semantic definition is:\r\n\r\n> modifyTVar :: TVar a -> (a -> a) -> STM ()\r\n> modifyTVar v f = readTVar v >>= writeTVar v . f\r\n\r\nHowever, explicitly reading then writing the TVar introduces unnecessary interference between transactions. The value held by the TVar does not affect the behavior of the transaction. modifyTVar should not interfere with other transactions that only writeTVar or modifyTVar.\r\n\r\nEven if a non-interfering implementation isn't feasible due to the underlying implementation of GHC's STM, providing the function would provide a point for a transparent upgrade in the future. ","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/4316Interactive "do" notation in GHCi2023-02-28T12:17:37ZmitarInteractive "do" notation in GHCiEnable GHCi to run commands under StateT monad based on IO or maybe even any other monad based on IO. So that you could for example exec a state and "fall" into this monad.
This could be generalized by supporting interactive "do" notati...Enable GHCi to run commands under StateT monad based on IO or maybe even any other monad based on IO. So that you could for example exec a state and "fall" into this monad.
This could be generalized by supporting interactive "do" notation. Currently doing something like:
```
(flip execStateT) state $ do
```
raises "Empty 'do' construct" warning, but GHCi could go into interactive mode where it would be possible to write one command after another and it would execute them.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.12.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mmitar@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Enable GHCi to run commands under StateT monad based on IO","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mmitar@gmail.com"],"type":"FeatureRequest","description":"Enable GHCi to run commands under StateT monad based on IO or maybe even any other monad based on IO. So that you could for example exec a state and \"fall\" into this monad.\r\n\r\nThis could be generalized by supporting interactive \"do\" notation. Currently doing something like:\r\n\r\n{{{\r\n(flip execStateT) state $ do\r\n}}}\r\n\r\nraises \"Empty 'do' construct\" warning, but GHCi could go into interactive mode where it would be possible to write one command after another and it would execute them.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4222Template Haskell lets you reify supposedly-abstract data types2019-07-07T19:00:02ZSimon Peyton JonesTemplate Haskell lets you reify supposedly-abstract data typesSerguey Zefirov writes ([on Haskell cafe](http://www.haskell.org/pipermail/haskell-cafe/2010-July/079802.html)) "Data.Map.Map and Data.Set.Set are exported abstractly, without exposing knowledge about their internal structure.
I cannot ...Serguey Zefirov writes ([on Haskell cafe](http://www.haskell.org/pipermail/haskell-cafe/2010-July/079802.html)) "Data.Map.Map and Data.Set.Set are exported abstractly, without exposing knowledge about their internal structure.
I cannot directly create my own class instances for them because of that. But I found that I can write Template Haskell code that could do that - those data types could be reified just fine."
Good point. It's not quite clear what a better design should be. Haskell controls data abstraction by whether or not the constructors of the data type are exported. But they might be exported by the module that *defined* them, but *not* to "clients" of the data type. So the data type is abstract to some importers but concrete to others.
So when should TH let you reify the representation of a data type? Maybe it should let you do so iff
- The data constructors of the data type are in scope (somehow) at the reification site
So, to take an example:
```
module Conc( T(..), Blah(..) ) where
data T = T1 | T2 Blah
data Blah = A | B
module Abs( T, Blah ) where
import Conc
module ReifyA where
import Abs
foo = reify ''T
module ReifyC where
import Conc
foo = reify ''T
```
So the `reify` in `ReifyC.foo` would "see" the data constructors of `T`, but not the one in `ReifyA`.
But this approach raises related questions.
- What if some, but not all, of `T`'s data constructors are in scope?
- What if the data constructors are all in scope, but some mention a type that is not in scope? For example, suppose type `Blah` is not in scope, but you reify `T`?
- At the moment, when you reify a data type you get its `Dec`. But if `T` is abstract, what `Dec` can we give it? Just giving it an empty constructor list seems wrong; after all, it might really *be* a zero-constructor data type. I suspect we may want a richer data type for `Info` (ie what `reify` returns).
All these require design thinking. Does anyone want to lead that debate? Otherwise things will probably stay as they are.
I've labelled this as a feature request, although it is a kind of bug, because of this design component.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.12.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | sergueyz@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell lets you reify supposedly-abstract data types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["sergueyz@gmail.com"],"type":"FeatureRequest","description":"Serguey Zefirov writes ([http://www.haskell.org/pipermail/haskell-cafe/2010-July/079802.html on Haskell cafe]) \"Data.Map.Map and Data.Set.Set are exported abstractly, without exposing knowledge about their internal structure.\r\n\r\nI cannot directly create my own class instances for them because of that. But I found that I can write Template Haskell code that could do that - those data types could be reified just fine.\" \r\n\r\nGood point. It's not quite clear what a better design should be. Haskell controls data abstraction by whether or not the constructors of the data type are exported. But they might be exported by the module that ''defined'' them, but ''not'' to \"clients\" of the data type. So the data type is abstract to some importers but concrete to others.\r\n\r\nSo when should TH let you reify the representation of a data type? Maybe it should let you do so iff\r\n * The data constructors of the data type are in scope (somehow) at the reification site\r\nSo, to take an example:\r\n{{{\r\nmodule Conc( T(..), Blah(..) ) where\r\n data T = T1 | T2 Blah\r\n data Blah = A | B\r\n\r\nmodule Abs( T, Blah ) where\r\n import Conc\r\n\r\nmodule ReifyA where\r\n import Abs\r\n\r\n foo = reify ''T\r\n\r\nmodule ReifyC where\r\n import Conc\r\n\r\n foo = reify ''T\r\n}}}\r\nSo the `reify` in `ReifyC.foo` would \"see\" the data constructors of `T`, but not the one in `ReifyA`.\r\n\r\nBut this approach raises related questions. \r\n\r\n * What if some, but not all, of `T`'s data constructors are in scope?\r\n\r\n * What if the data constructors are all in scope, but some mention a type that is not in scope? For example, suppose type `Blah` is not in scope, but you reify `T`?\r\n\r\n * At the moment, when you reify a data type you get its `Dec`. But if `T` is abstract, what `Dec` can we give it? Just giving it an empty constructor list seems wrong; after all, it might really ''be'' a zero-constructor data type. I suspect we may want a richer data type for `Info` (ie what `reify` returns).\r\n\r\nAll these require design thinking. Does anyone want to lead that debate? Otherwise things will probably stay as they are.\r\n\r\nI've labelled this as a feature request, although it is a kind of bug, because of this design component.\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4213LLVM: Add support for TNTC to LLVM compiler suite2019-07-07T19:00:05ZdtereiLLVM: Add support for TNTC to LLVM compiler suiteAt the moment we handle TNTC in the LLVM backend in two different ways:
Linux/Windows: We use the GNU As subsections feature to order sections. Works very nicely. Slight hack in that we create special section names that contain comments...At the moment we handle TNTC in the LLVM backend in two different ways:
Linux/Windows: We use the GNU As subsections feature to order sections. Works very nicely. Slight hack in that we create special section names that contain comments. (Asm injection)
Mac: Mac assembler doesn't support the GNU As subsections feature, so we post-process the assembly code produced by llc.
Both these methods (especially Mac) are hacks. It would be better to extend LLVM to support the TNTC feature.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 6.13 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LLVM: Add support for TNTC to LLVM compiler suite","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dterei"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"At the moment we handle TNTC in the LLVM backend in two different ways:\r\n\r\nLinux/Windows: We use the GNU As subsections feature to order sections. Works very nicely. Slight hack in that we create special section names that contain comments. (Asm injection)\r\n\r\nMac: Mac assembler doesn't support the GNU As subsections feature, so we post-process the assembly code produced by llc.\r\n\r\nBoth these methods (especially Mac) are hacks. It would be better to extend LLVM to support the TNTC feature.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/4180do not consider associativity for unary minus for fixity resolution2021-04-26T08:39:54ZChristian Maederdo not consider associativity for unary minus for fixity resolution1. currently an expression "1 + - 1" is rejected, because "1 + (-1)" looks as being bracketed to the right, whereas + and - are left associative. However, no other bracketing is possible, so "1 + - 1" is unambiguous and should not be sub...1. currently an expression "1 + - 1" is rejected, because "1 + (-1)" looks as being bracketed to the right, whereas + and - are left associative. However, no other bracketing is possible, so "1 + - 1" is unambiguous and should not be subject to further fixity resolution.
1. if an infix expressions starts with an unary minus, the associativity should not matter for the unary minus. Why should "- 1 \#\# 1" be rejected for a right- or non-assoc operator "\#\#"? Precedence alone is sufficient to decide between "(- 1) \#\# 1" and "- (1 \#\# 1)". The latter choice is taken for a higher precedence of the infix operator and the former choice should always be taken
for an equal or lower precedence as is done for "- 1 + 1", but without looking at associativity!
I'll attach an alternative fixity resolution in the spirit of
1. 6 of http://www.haskell.org/\~simonmar/haskell-2010-draft-report-2/haskellch10.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"do not consider associativity for unary minus for fixity resolution","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":["fixity","resolution"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"1. currently an expression \"1 + - 1\" is rejected, because \"1 + (-1)\" looks as being bracketed to the right, whereas + and - are left associative. However, no other bracketing is possible, so \"1 + - 1\" is unambiguous and should not be subject to further fixity resolution.\r\n\r\n2. if an infix expressions starts with an unary minus, the associativity should not matter for the unary minus. Why should \"- 1 ## 1\" be rejected for a right- or non-assoc operator \"##\"? Precedence alone is sufficient to decide between \"(- 1) ## 1\" and \"- (1 ## 1)\". The latter choice is taken for a higher precedence of the infix operator and the former choice should always be taken\r\nfor an equal or lower precedence as is done for \"- 1 + 1\", but without looking at associativity!\r\n\r\nI'll attach an alternative fixity resolution in the spirit of\r\n10.6 of http://www.haskell.org/~simonmar/haskell-2010-draft-report-2/haskellch10.html\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4096New primops for indexing: index*OffAddrUsing# etc2020-10-20T12:40:55ZSimon Peyton JonesNew primops for indexing: index*OffAddrUsing# etcHere's an email from Roman, and response from Simon. Making a ticket so it's kept as an idea.
In package vector, primitive vectors (the ones that `Data.Vector.Unboxed` is built on top of) are represented as follows (`ByteArray` and frie...Here's an email from Roman, and response from Simon. Making a ticket so it's kept as an idea.
In package vector, primitive vectors (the ones that `Data.Vector.Unboxed` is built on top of) are represented as follows (`ByteArray` and friends are wrappers for various GHC primitives provided by package primitive):
```
data Vector a = Vector Int -- offset into the ByteArray
Int -- length
ByteArray -- data
```
This representation supports cheap slicing which is quite crucial. However, indexing into such vectors is a bit more expensive than necessary:
```
index (Vector i _ arr) j = indexByteArray arr (i+j)
```
Ultimately, this requires 2 additions to get the element's address:
```
<base address off the ByteArray> + ((i + j) * <size of element>)
```
I'd like to always allocate pinned `ByteArrays` and store the starting address of the vector instead of the offset:
```
data Vector a = Vector Addr
Int
ByteArray
```
This would make indexing cheaper as it would require only one addition:
```
index (Vector addr i _) = indexOffAddr addr i
```
This is quite a big deal if indexing happens in an inner loop (some algorithms become up to 20% faster). Of course, the backend could optimise the offset-based version by performing partial redundancy elimination but it doesn't and it probably wouldn't get all interesting cases even if it did. So the second version is better.
The problem is that I can't implement it because I must touch the `ByteArray` after accessing the memory. This results in code like this which hides the constructor, breaking various optimisations:
```
case indexIntOffAddr# addr# i# of { n# ->
case touch# arr# realWorld# of { _ -> I# n# }}
```
After thinking about this for a while, I came up with two possible solutions. One is to provide a "pure" version of touch\#:
```
use# :: o -> o' -> o'
```
such that use\# x y = y. This would change the code above to:
```
I# (use# arr# (indexIntOffAddr# addr# i#))
```
I don't know how to implement this, though, because use\# would have to be able to return arbitrary (unboxed) types and the code generator doesn't really seem to support this.
A perhaps simpler solution is to add a new set of primitives:
```
indexIntOffAddrUsing# :: o -> Addr# -> Int# -> Int#
...
```
These would take an additional argument which they'd touch and otherwise ignore. The code would then become:
```
I# (indexIntOffAddrUsing# arr# addr# i#)
```
Incidentally, the `index*OffAddr#` primitives don't seem to be used anywhere. \[Not true: there are a handful of uses of `index*OffAddr#` in libraries/base, mainly GHC.Base.\]
Simon replies:
`indexIntOffAddrUsing#` seems like the way to go, I can't think of a better alternative.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"New primops for indexing: index*OffAddrUsing# etc","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Here's an email from Roman, and response from Simon. Making a ticket so it's kept as an idea.\r\n\r\nIn package vector, primitive vectors (the ones that `Data.Vector.Unboxed` is built on top of) are represented as follows (`ByteArray` and friends are wrappers for various GHC primitives provided by package primitive):\r\n{{{\r\ndata Vector a = Vector Int -- offset into the ByteArray\r\n Int -- length\r\n ByteArray -- data\r\n}}}\r\nThis representation supports cheap slicing which is quite crucial. However, indexing into such vectors is a bit more expensive than necessary:\r\n{{{\r\nindex (Vector i _ arr) j = indexByteArray arr (i+j)\r\n}}}\r\nUltimately, this requires 2 additions to get the element's address:\r\n{{{\r\n <base address off the ByteArray> + ((i + j) * <size of element>)\r\n}}}\r\nI'd like to always allocate pinned `ByteArrays` and store the starting address of the vector instead of the offset:\r\n{{{\r\ndata Vector a = Vector Addr\r\n Int\r\n ByteArray\r\n}}}\r\nThis would make indexing cheaper as it would require only one addition:\r\n{{{\r\nindex (Vector addr i _) = indexOffAddr addr i\r\n}}}\r\nThis is quite a big deal if indexing happens in an inner loop (some algorithms become up to 20% faster). Of course, the backend could optimise the offset-based version by performing partial redundancy elimination but it doesn't and it probably wouldn't get all interesting cases even if it did. So the second version is better.\r\n\r\nThe problem is that I can't implement it because I must touch the `ByteArray` after accessing the memory. This results in code like this which hides the constructor, breaking various optimisations:\r\n{{{\r\n case indexIntOffAddr# addr# i# of { n# ->\r\n case touch# arr# realWorld# of { _ -> I# n# }}\r\n}}}\r\nAfter thinking about this for a while, I came up with two possible solutions. One is to provide a \"pure\" version of touch#:\r\n{{{\r\n use# :: o -> o' -> o'\r\n}}}\r\nsuch that use# x y = y. This would change the code above to:\r\n{{{\r\n I# (use# arr# (indexIntOffAddr# addr# i#))\r\n}}}\r\nI don't know how to implement this, though, because use# would have to be able to return arbitrary (unboxed) types and the code generator doesn't really seem to support this.\r\n\r\nA perhaps simpler solution is to add a new set of primitives:\r\n{{{\r\n indexIntOffAddrUsing# :: o -> Addr# -> Int# -> Int#\r\n ...\r\n}}}\r\nThese would take an additional argument which they'd touch and otherwise ignore. The code would then become:\r\n{{{\r\n I# (indexIntOffAddrUsing# arr# addr# i#)\r\n}}}\r\nIncidentally, the `index*OffAddr#` primitives don't seem to be used anywhere. [Not true: there are a handful of uses of `index*OffAddr#` in libraries/base, mainly GHC.Base.]\r\n\r\nSimon replies:\r\n`indexIntOffAddrUsing#` seems like the way to go, I can't think of a better alternative.\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1