GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:04:07Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15563Typo in the documentation for Numeric.Natural.2019-07-07T18:04:07ZAndrés Sicard-RamírezTypo in the documentation for Numeric.Natural.The [documentation](https://downloads.haskell.org/~ghc/8.4.3/docs/html/libraries/base-4.11.1.0/Numeric-Natural.html) for `Numeric.Natural` says
```
>>> 2^20 :: Natural
1267650600228229401496703205376
```
Please replace the `20` by `100...The [documentation](https://downloads.haskell.org/~ghc/8.4.3/docs/html/libraries/base-4.11.1.0/Numeric-Natural.html) for `Numeric.Natural` says
```
>>> 2^20 :: Natural
1267650600228229401496703205376
```
Please replace the `20` by `100`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typo in the documentation for Numeric.Natural.","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The [https://downloads.haskell.org/~ghc/8.4.3/docs/html/libraries/base-4.11.1.0/Numeric-Natural.html documentation] for `Numeric.Natural` says\r\n\r\n{{{\r\n>>> 2^20 :: Natural\r\n1267650600228229401496703205376\r\n}}}\r\n\r\nPlease replace the `20` by `100`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15556Inconsistent kind output for (->)2019-07-07T18:04:09ZcvladInconsistent kind output for (->)The kind for (-\>) seems to be (uniquely?) verbose in ghc \>= 8.2.2:
`(->) :: TYPE q -> TYPE r -> *`
Unlike all other things I was able to check. Is this intended?
<details><summary>Trac metadata</summary>
| Trac field | ...The kind for (-\>) seems to be (uniquely?) verbose in ghc \>= 8.2.2:
`(->) :: TYPE q -> TYPE r -> *`
Unlike all other things I was able to check. Is this intended?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Inconsistent kind output for (->)","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The kind for (->) seems to be (uniquely?) verbose in ghc >= 8.2.2:\r\n\r\n{{{(->) :: TYPE q -> TYPE r -> *}}}\r\n\r\nUnlike all other things I was able to check. Is this intended?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15541package environment files and the GHC API2023-03-21T12:06:34Zlspitznerpackage environment files and the GHC APIThe GHC API respects package environment files, which is not documented and was not announced.
I consider this to be at least a severe documentation bug.
Afaik this goes back to ghc-8.0.
#15513 is a ticket that essentially asks for th...The GHC API respects package environment files, which is not documented and was not announced.
I consider this to be at least a severe documentation bug.
Afaik this goes back to ghc-8.0.
#15513 is a ticket that essentially asks for the corresponding entry in the migration guide.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"package environment files and the GHC API","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["environment","package"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC API respects package environment files, which is not documented and was not announced.\r\n\r\nI consider this to be at least a severe documentation bug.\r\n\r\nAfaik this goes back to ghc-8.0.\r\n\r\n#15513 is a ticket that essentially asks for the corresponding entry in the migration guide.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15491No control over synopsis in Library Documentation2019-07-07T18:04:30Zh001No control over synopsis in Library DocumentationYou can not hide synopsis of Library Documentation (Microsoft Edge 41.16299.402.0, Microsoft EdgeHTML 16.16299) so that reading the documentation is impossible.
<details><summary>Trac metadata</summary>
| Trac field | Value...You can not hide synopsis of Library Documentation (Microsoft Edge 41.16299.402.0, Microsoft EdgeHTML 16.16299) so that reading the documentation is impossible.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"No control over synopsis in Library Documentation","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"You can not hide synopsis of Library Documentation (Microsoft Edge 41.16299.402.0, Microsoft EdgeHTML 16.16299) so that reading the documentation is impossible.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15410Fix typos in docs2019-07-07T18:05:03ZSasha Bogicevicsasa.bogicevic@pm.meFix typos in docsFix some typos in documenatation
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.4.3 |
| Type | Bug ...Fix some typos in documenatation
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fix typos in docs","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Fix some typos in documenatation","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Sasha Bogicevicsasa.bogicevic@pm.meSasha Bogicevicsasa.bogicevic@pm.mehttps://gitlab.haskell.org/ghc/ghc/-/issues/15406Fix a small typo in TcType.hs2019-07-07T18:05:04ZSasha Bogicevicsasa.bogicevic@pm.meFix a small typo in TcType.hs> > not substTy, bucause the latter uses smart constructors that do
s/bucause/because
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version ...> > not substTy, bucause the latter uses smart constructors that do
s/bucause/because
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fix a small typo in TcType.hs","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":">> not substTy, bucause the latter uses smart constructors that do\r\ns/bucause/because","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Sasha Bogicevicsasa.bogicevic@pm.meSasha Bogicevicsasa.bogicevic@pm.mehttps://gitlab.haskell.org/ghc/ghc/-/issues/15405Typo in trac ticket number2019-07-07T18:05:04ZSasha Bogicevicsasa.bogicevic@pm.meTypo in trac ticket numberThis line should refer to trac issue #14873 not #114873
https://github.com/ghc/ghc/blob/53649947223f197cf93e26393486f578d56c46c6/compiler/typecheck/TcHsType.hs\#L1153
<details><summary>Trac metadata</summary>
| Trac field ...This line should refer to trac issue #14873 not #114873
https://github.com/ghc/ghc/blob/53649947223f197cf93e26393486f578d56c46c6/compiler/typecheck/TcHsType.hs\#L1153
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typo in trac ticket number","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This line should refer to trac issue #14873 not #114873\r\n\r\nhttps://github.com/ghc/ghc/blob/53649947223f197cf93e26393486f578d56c46c6/compiler/typecheck/TcHsType.hs#L1153","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Sasha Bogicevicsasa.bogicevic@pm.meSasha Bogicevicsasa.bogicevic@pm.mehttps://gitlab.haskell.org/ghc/ghc/-/issues/15266Add QuantifiedConstraints to release notes2020-06-23T23:16:09ZRichard Eisenbergrae@richarde.devAdd QuantifiedConstraints to release notesIt seems `-XQuantifiedConstraints` never made it into the release notes. We should fix this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...It seems `-XQuantifiedConstraints` never made it into the release notes. We should fix this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add QuantifiedConstraints to release notes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems `-XQuantifiedConstraints` never made it into the release notes. We should fix this.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15245Data family promotion is possible2021-11-06T12:06:45ZVladislav ZavialovData family promotion is possibleThe User's Guide states that data families cannot be promoted, even with `-XTypeInType`:
> We promote data types and newtypes; type synonyms and type/data families are not promoted.
>
> The flag TypeInType (which implies DataKinds) rela...The User's Guide states that data families cannot be promoted, even with `-XTypeInType`:
> We promote data types and newtypes; type synonyms and type/data families are not promoted.
>
> The flag TypeInType (which implies DataKinds) relaxes some of these restrictions, allowing:
>
> Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types.
And yet the following code typechecks and runs:
```hs
{-# LANGUAGE TypeFamilies, TypeInType, TypeApplications #-}
import Type.Reflection
data family K
data instance K = MkK
main = print (typeRep @'MkK)
```
Is this a GHC bug or a documentation bug? I asked in IRC but I'm still confused:
```
<int-index> The user guide states that data families aren't promoted even when -XTypeInType is enabled. Where's the logic that ensures this? I checked with `data family K; data instance K = MkK` and I can use `'MkK` with no errors/warnings.
<int-index> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#overview "Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types."
<int-index> Is this info outdated?
<RyanGlScott> int-index: Is this in GHCi?
<RyanGlScott> It certainly fails in GHC
<RyanGlScott> But I think I understand why the former works
<int-index> RyanGlScott, yes, I'm checking this in GHCi
<RyanGlScott> int-index: So here's my understanding of how this works
<RyanGlScott> GHC kind-checks top-level declarations using a rather primitive SCC analysis
<RyanGlScott> In particular, it's primitive in the sense that data family instances give it a lot of trouble
<RyanGlScott> If you tried taking your code and putting it into a standalone .hs file and compiling that, then it would definitely complain about a promoted use of MkT
<RyanGlScott> As luck would have it, though, you were trying things out in GHCi
<RyanGlScott> Which essentially checks each line of input as its own strongly connected group of declarations
<RyanGlScott> So you can define MkT on one line and promote it in subsequent lines, since they're separate in the sense
<RyanGlScott> *that sense
<int-index> this sounds related to Trac #12088, and then I could work around it in GHC by using `$(return [])`, so data families are actually promoted anyway and this has nothing to do with GHC needing more powerful type theory
<RyanGlScott> Well, it does need more powerful type theory in the sense that that's a prerequisite for making the SCC analysis for kind-checking sophisticated enough to handle this
<RyanGlScott> But yes, it's quite simple to work around by using Template Haskell to explicitly split up groups.
<int-index> https://gist.github.com/int-index/c6cc1e20c4b9b5c99af40ee4e23ecb61 this works and no template haskell involved
<int-index> The reason I'm asking is that I'm touching this part of the User's Guide and I don't know what to write there.
<RyanGlScott> Huh, now that's interesting
<int-index> RyanGlScott, the only check I could find that controls what's promoted and what's not is 'isLegacyPromotableDataCon' - and enabling -XTypeInType disables this check.
<RyanGlScott> int-index: Right, that's baffling me
<RyanGlScott> Since that's supposed to be checked every time you promote a data constructor (I think)
<RyanGlScott> int-index: File a bug about that, I suppose
<RyanGlScott> Richard (who's sitting next to me right now) seems to think that that shouldn't be possible
<int-index> RyanGlScott, the thing is, I happily removed this check completely in D4748. Does this mean I have to restore a weaker version of it that only checks for data families? Why?
<int-index> Is it bad that -XDataKinds promotes data family constructors? Looks like I can just remove the "restrictions" part of the user guide and be done with it
<RyanGlScott> int-index: In theory, that shouldn't be possible
<int-index> OK, then what the check should be? No data families, any other restrictions?
<RyanGlScott> I might qualify that with "no data family instances defined in the same module"
<RyanGlScott> (Or to be precise, in the same SCC, but that's probably too technical for the users' guide)
<int-index> Well, this sounds hard to check. I was thinking along the lines of keeping the 'not (isFamInstTyCon (dataConTyCon dc))' part of the check...
<RyanGlScott> Oh, I thought you were only changing the users' guide :)
<int-index> Well, at this point I'm confused if I should change only the user guide or the check as well. If data families shouldn't be promoted ever, then I'll change GHC. If the limitation is about the current SCC group, I can just mention Trac #12088 as a known infelicity in the User's Guide
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | RyanGlScott, goldfire |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data family promotion is possible","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":["RyanGlScott","goldfire"],"type":"Bug","description":"The User's Guide states that data families cannot be promoted, even with `-XTypeInType`:\r\n\r\n> We promote data types and newtypes; type synonyms and type/data families are not promoted.\r\n>\r\n> The flag TypeInType (which implies DataKinds) relaxes some of these restrictions, allowing:\r\n>\r\n> Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types.\r\n\r\nAnd yet the following code typechecks and runs:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeFamilies, TypeInType, TypeApplications #-}\r\n\r\nimport Type.Reflection\r\n\r\ndata family K\r\ndata instance K = MkK\r\n\r\nmain = print (typeRep @'MkK)\r\n}}}\r\n\r\nIs this a GHC bug or a documentation bug? I asked in IRC but I'm still confused:\r\n\r\n{{{\r\n<int-index> The user guide states that data families aren't promoted even when -XTypeInType is enabled. Where's the logic that ensures this? I checked with `data family K; data instance K = MkK` and I can use `'MkK` with no errors/warnings.\r\n<int-index> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#overview \"Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types.\"\r\n<int-index> Is this info outdated?\r\n<RyanGlScott> int-index: Is this in GHCi?\r\n<RyanGlScott> It certainly fails in GHC\r\n<RyanGlScott> But I think I understand why the former works\r\n<int-index> RyanGlScott, yes, I'm checking this in GHCi\r\n<RyanGlScott> int-index: So here's my understanding of how this works\r\n<RyanGlScott> GHC kind-checks top-level declarations using a rather primitive SCC analysis\r\n<RyanGlScott> In particular, it's primitive in the sense that data family instances give it a lot of trouble\r\n<RyanGlScott> If you tried taking your code and putting it into a standalone .hs file and compiling that, then it would definitely complain about a promoted use of MkT\r\n<RyanGlScott> As luck would have it, though, you were trying things out in GHCi\r\n<RyanGlScott> Which essentially checks each line of input as its own strongly connected group of declarations\r\n<RyanGlScott> So you can define MkT on one line and promote it in subsequent lines, since they're separate in the sense\r\n<RyanGlScott> *that sense\r\n<int-index> this sounds related to Trac #12088, and then I could work around it in GHC by using `$(return [])`, so data families are actually promoted anyway and this has nothing to do with GHC needing more powerful type theory\r\n<RyanGlScott> Well, it does need more powerful type theory in the sense that that's a prerequisite for making the SCC analysis for kind-checking sophisticated enough to handle this\r\n<RyanGlScott> But yes, it's quite simple to work around by using Template Haskell to explicitly split up groups.\r\n<int-index> https://gist.github.com/int-index/c6cc1e20c4b9b5c99af40ee4e23ecb61 this works and no template haskell involved\r\n<int-index> The reason I'm asking is that I'm touching this part of the User's Guide and I don't know what to write there.\r\n<RyanGlScott> Huh, now that's interesting\r\n<int-index> RyanGlScott, the only check I could find that controls what's promoted and what's not is 'isLegacyPromotableDataCon' - and enabling -XTypeInType disables this check.\r\n<RyanGlScott> int-index: Right, that's baffling me\r\n<RyanGlScott> Since that's supposed to be checked every time you promote a data constructor (I think)\r\n<RyanGlScott> int-index: File a bug about that, I suppose\r\n<RyanGlScott> Richard (who's sitting next to me right now) seems to think that that shouldn't be possible\r\n<int-index> RyanGlScott, the thing is, I happily removed this check completely in D4748. Does this mean I have to restore a weaker version of it that only checks for data families? Why?\r\n<int-index> Is it bad that -XDataKinds promotes data family constructors? Looks like I can just remove the \"restrictions\" part of the user guide and be done with it\r\n<RyanGlScott> int-index: In theory, that shouldn't be possible\r\n<int-index> OK, then what the check should be? No data families, any other restrictions?\r\n<RyanGlScott> I might qualify that with \"no data family instances defined in the same module\"\r\n<RyanGlScott> (Or to be precise, in the same SCC, but that's probably too technical for the users' guide)\r\n<int-index> Well, this sounds hard to check. I was thinking along the lines of keeping the 'not (isFamInstTyCon (dataConTyCon dc))' part of the check...\r\n<RyanGlScott> Oh, I thought you were only changing the users' guide :)\r\n<int-index> Well, at this point I'm confused if I should change only the user guide or the check as well. If data families shouldn't be promoted ever, then I'll change GHC. If the limitation is about the current SCC group, I can just mention Trac #12088 as a known infelicity in the User's Guide\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15217Typo in documentation2019-07-07T18:13:45ZelpinalTypo in documentationIn "10.8.5. Overloaded labels" it says "an overloaded label can written with a prefix hash," but I think it should be "an overloaded label can \*\*be\*\* written with a prefix hash."
<details><summary>Trac metadata</summary>
| Trac fie...In "10.8.5. Overloaded labels" it says "an overloaded label can written with a prefix hash," but I think it should be "an overloaded label can \*\*be\*\* written with a prefix hash."
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typo in documentation","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In \"10.8.5. Overloaded labels\" it says \"an overloaded label can written with a prefix hash,\" but I think it should be \"an overloaded label can **be** written with a prefix hash.\"","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15146Documentation: ScopedTypeVariables feature not mentioned/misleadingly described2019-07-07T18:14:04ZAntCDocumentation: ScopedTypeVariables feature not mentioned/misleadingly describedConsider these dead-simple examples that use a signature with `tyvars` on a pattern
```
-- no separate signature for bar, baz; tyvar aa not in scope from anywhere
bar (x :: aa) = x :: aa
baz (Just (x :: aa)) = x :: aa
-- there could ...Consider these dead-simple examples that use a signature with `tyvars` on a pattern
```
-- no separate signature for bar, baz; tyvar aa not in scope from anywhere
bar (x :: aa) = x :: aa
baz (Just (x :: aa)) = x :: aa
-- there could be signatures for bar, baz; they might use tyvar aa; but
-- bar :: aa -> aa -- } no explicit forall
-- baz :: Maybe aa -> aa -- }
```
Those equations with signatures on the patterns aren't valid Haskell 2010, so ghc rejects and suggests you need `ScopedTypeVariables`. Then they compile OK.
Would I expect from [the User Guide documentation](https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/glasgow_exts.html#lexically-scoped-type-variables) those equations to be valid? I think not, and I see lots of questions on StackOverflow from people confused why they must use explicit `forall` -- and some equally confused answers failing to mention that no you don't necessarily. Arguably, all of the examples in the docos could be expressed equivalently (and less confusingly for beginners) using this style with pattern signatures rather than explicit `forall` bindings.
(Misleading) snippets from the docos:
\[\[BR\]\]\[\[BR\]\]
> 1. 16 Enable lexical scoping of type variables explicitly introduced with `forall`.
This comment is indented, so is really explaining that `ScopedTypeVariables` implies `ExplicitForall`. But it fails to explain that you're not forced to use explicit `forall`.
\[\[BR\]\]\[\[BR\]\]
> 1. 16 opening example\[\[BR\]\]
>
> The type signature for `f` brings the type variable `a` into scope, because of the explicit `forall` ...
Fails to mentin that you could achieve the same effect without explicit `forall`.
\[\[BR\]\]\[\[BR\]\]
> 1. 16.4 ... in all patterns *other* than pattern bindings, a pattern type signature may mention a type variable that is not in scope; in this case, *the signature brings that type variable into scope*.
This *might* be telling that the `bar, baz` above examples are valid, but there is not an example. Furthermore the comment following the `MkT` existential data constructor example undermines that interpretation:
> 1. .. in this situation (and only then), a pattern type signature can mention a type variable that is not already in scope ... If all this seems a little odd, ...
What is "this situation"? What is "this" that seems odd? The pattern signature binding `(MkT [t :: a])` looks the same as `baz` above's `(Just (x :: aa))`; it's merely that `Just` is not existential.
There might be a signature given for `baz`, and it might use `tyvar aa`. But it ''doesn't'' bring `aa` into scope for the equations \*\*unless\*\* that signature has explicit `forall`. That's not made clear.
My first several readings of "situation (and only then) ... odd ..." were that this style of pattern signature to bind a `tyvar` applied only for existentials.
\[\[BR\]\]\[\[BR\]\]\[\[BR\]\]
BTW, some of the examples in the docos are not valid Haskell/give compilation errors because of lack of `( )` round the patterns with signatures.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Documentation: ScopedTypeVariables feature not mentioned/misleadingly described","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["ScopedTypeVariables"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider these dead-simple examples that use a signature with `tyvars` on a pattern\r\n\r\n{{{\r\n-- no separate signature for bar, baz; tyvar aa not in scope from anywhere\r\n\r\nbar (x :: aa) = x :: aa\r\n\r\nbaz (Just (x :: aa)) = x :: aa\r\n\r\n-- there could be signatures for bar, baz; they might use tyvar aa; but\r\n\r\n-- bar :: aa -> aa -- } no explicit forall\r\n-- baz :: Maybe aa -> aa -- } \r\n}}}\r\n\r\nThose equations with signatures on the patterns aren't valid Haskell 2010, so ghc rejects and suggests you need `ScopedTypeVariables`. Then they compile OK.\r\n\r\nWould I expect from [https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/glasgow_exts.html#lexically-scoped-type-variables the User Guide documentation] those equations to be valid? I think not, and I see lots of questions on StackOverflow from people confused why they must use explicit `forall` -- and some equally confused answers failing to mention that no you don't necessarily. Arguably, all of the examples in the docos could be expressed equivalently (and less confusingly for beginners) using this style with pattern signatures rather than explicit `forall` bindings.\r\n\r\n(Misleading) snippets from the docos:\r\n[[BR]][[BR]]\r\n\r\n> 10.16 Enable lexical scoping of type variables explicitly introduced with `forall`.\r\n\r\nThis comment is indented, so is really explaining that `ScopedTypeVariables` implies `ExplicitForall`. But it fails to explain that you're not forced to use explicit `forall`.\r\n[[BR]][[BR]]\r\n> 10.16 opening example[[BR]]\r\n> The type signature for `f` brings the type variable `a` into scope, because of the explicit `forall` ...\r\n\r\nFails to mentin that you could achieve the same effect without explicit `forall`.\r\n[[BR]][[BR]]\r\n> 10.16.4 ... in all patterns ''other'' than pattern bindings, a pattern type signature may mention a type variable that is not in scope; in this case, ''the signature brings that type variable into scope''.\r\n\r\nThis ''might'' be telling that the `bar, baz` above examples are valid, but there is not an example. Furthermore the comment following the `MkT` existential data constructor example undermines that interpretation:\r\n\r\n> ... in this situation (and only then), a pattern type signature can mention a type variable that is not already in scope ... If all this seems a little odd, ...\r\n\r\nWhat is \"this situation\"? What is \"this\" that seems odd? The pattern signature binding `(MkT [t :: a])` looks the same as `baz` above's `(Just (x :: aa))`; it's merely that `Just` is not existential.\r\n\r\nThere might be a signature given for `baz`, and it might use `tyvar aa`. But it ''doesn't'' bring `aa` into scope for the equations **unless** that signature has explicit `forall`. That's not made clear.\r\n\r\nMy first several readings of \"situation (and only then) ... odd ...\" were that this style of pattern signature to bind a `tyvar` applied only for existentials.\r\n[[BR]][[BR]][[BR]]\r\nBTW, some of the examples in the docos are not valid Haskell/give compilation errors because of lack of `( )` round the patterns with signatures.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15134enumFrom... aren't really documented.2019-07-07T18:14:07ZDavid FeuerenumFrom... aren't really documented.The Haddocks for `enumFrom`, `enumFromTo`, etc., say nothing whatsoever about what these functions actually do.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------...The Haddocks for `enumFrom`, `enumFromTo`, etc., say nothing whatsoever about what these functions actually do.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"enumFrom... aren't really documented.","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The Haddocks for `enumFrom`, `enumFromTo`, etc., say nothing whatsoever about what these functions actually do.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1AzelAzelhttps://gitlab.haskell.org/ghc/ghc/-/issues/15086hT profiling option2019-07-07T18:14:19ZEric CrocketthT profiling option[The docs](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html#rts-options-for-heap-profiling) indicate that you can pass `-hT` as an RTS option for memory profiling "by heap closure type". However, GHC 8.4.2 c...[The docs](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html#rts-options-for-heap-profiling) indicate that you can pass `-hT` as an RTS option for memory profiling "by heap closure type". However, GHC 8.4.2 claims `invalid heap profile options: -hT`, and this option is not listed among the usage options printed with the error.
The user guide for GHC 8.2.2 also mentions -hT, and I believe that GHC-8.2.2 also did not permit the option.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.2 |
| 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":"hT profiling option","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"[https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html#rts-options-for-heap-profiling The docs] indicate that you can pass `-hT` as an RTS option for memory profiling \"by heap closure type\". However, GHC 8.4.2 claims `invalid heap profile options: -hT`, and this option is not listed among the usage options printed with the error.\r\n\r\nThe user guide for GHC 8.2.2 also mentions -hT, and I believe that GHC-8.2.2 also did not permit the option.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14869Documentation for isLiftedTypeKind is incorrect2019-07-07T18:15:15ZRyan ScottDocumentation for isLiftedTypeKind is incorrectI [noticed recently](https://github.com/ghc-proposals/ghc-proposals/pull/32#issuecomment-369252383) that Template Haskell reifies `Constraint` as `Type`:
```
$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive
GHCi, version 8.5.20180...I [noticed recently](https://github.com/ghc-proposals/ghc-proposals/pull/32#issuecomment-369252383) that Template Haskell reifies `Constraint` as `Type`:
```
$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive
GHCi, version 8.5.20180221: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> :set -XTypeFamilies -XTemplateHaskell
λ> :m + Data.Kind Language.Haskell.TH
λ> type family Foo :: Constraint
λ> putStrLn $(reify ''Foo >>= stringE . pprint)
type family Ghci1.Foo :: *
```
The root of the issue can be traced back to the `isLiftedTypeKind` function, which `TcSplice` uses to distinguish `Type` from `Constraint`. At least, that's what its [documentation](http://git.haskell.org/ghc.git/blob/df2c3b3364834d2fd038192c89348fc50a2e0475:/compiler/types/TyCoRep.hs#l721) claims:
```
-- | This version considers Constraint to be distinct from *. Returns True
-- if the argument is equivalent to Type and False otherwise.
isLiftedTypeKind :: Kind -> Bool
isLiftedTypeKind = is_TYPE is_lifted
where
is_lifted (TyConApp lifted_rep []) = lifted_rep `hasKey` liftedRepDataConKey
is_lifted _ = False
```
However, in practice this claim about treating `Constraint` and `Type` as distinct is false:
```
$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive -package ghc
GHCi, version 8.5.20180221: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> :m + TyCoRep TysWiredIn
λ> isLiftedTypeKind liftedTypeKind
True
λ> isLiftedTypeKind constraintKind
True
```
Either we should change the implementation of `isLiftedTypeKind` to match the documentation's claim, or change the documentation.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14665http://www.cminusminus.org/ is dead2019-07-07T18:16:06Zniteriahttp://www.cminusminus.org/ is deadThere are a couple of comments referring to it in the source, it's easy enough to find the original site at the mirror: http://www.cs.tufts.edu/\~nr/c--/index.html or from the wayback machine: https://web.archive.org/web/20080822062234/h...There are a couple of comments referring to it in the source, it's easy enough to find the original site at the mirror: http://www.cs.tufts.edu/\~nr/c--/index.html or from the wayback machine: https://web.archive.org/web/20080822062234/http://www.cminusminus.org/
If we no longer own the domain, perhaps it would be a good idea to move it under haskell.org somewhere?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"http://www.cminusminus.org/ is dead","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"There are a couple of comments referring to it in the source, it's easy enough to find the original site at the mirror: http://www.cs.tufts.edu/~nr/c--/index.html or from the wayback machine: https://web.archive.org/web/20080822062234/http://www.cminusminus.org/\r\n\r\nIf we no longer own the domain, perhaps it would be a good idea to move it under haskell.org somewhere?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14309Expand comment in hPutStrLn2021-12-11T14:21:50ZDavid FeuerExpand comment in hPutStrLnA comment on `hPutStrLn` reads
> An optimisation: we treat `hPutStrLn` specially, to avoid the
> overhead of a single `putChar '\n'`, which is quite high now that we
> have to encode eagerly.
This should reference some code or comment ...A comment on `hPutStrLn` reads
> An optimisation: we treat `hPutStrLn` specially, to avoid the
> overhead of a single `putChar '\n'`, which is quite high now that we
> have to encode eagerly.
This should reference some code or comment that explains why the cost is high, why we have to encode eagerly, what it even *means* to encode eagerly, etc.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Expand comment in hPutStrLn","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"A comment on `hPutStrLn` reads\r\n\r\n> An optimisation: we treat `hPutStrLn` specially, to avoid the\r\n> overhead of a single `putChar '\\n'`, which is quite high now that we\r\n> have to encode eagerly.\r\n\r\nThis should reference some code or comment that explains why the cost is high, why we have to encode eagerly, what it even ''means'' to encode eagerly, etc.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Sylvain HenrySylvain Henry