GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-02-25T01:14:07Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16603GHC 8.8-related changelogs omit several important major developments2020-02-25T01:14:07ZRyan ScottGHC 8.8-related changelogs omit several important major developmentsWhile looking at the various changelogs associated with GHC 8.8, I noticed several key omissions:
# `libraries/base/changelog.md`
* [x] The `4.13.0.0` entry makes no mention of `MonadFail` whatsoever.
# `docs/users_guide/8.8.1-notes....While looking at the various changelogs associated with GHC 8.8, I noticed several key omissions:
# `libraries/base/changelog.md`
* [x] The `4.13.0.0` entry makes no mention of `MonadFail` whatsoever.
# `docs/users_guide/8.8.1-notes.rst`
No mention of any of the following:
* [x] Visible kind application
* [x] More explicit `forall`s in type family equations and `RULES`
* [x] The `base` section also does not mention `MonadFail`. Ideally, it would also point to https://gitlab.haskell.org/ghc/ghc/wikis/proposal/monad-fail#adapting-old-code
* [x] The Template Haskell section makes no mention of visible kind applications nor more explicit `forall`s.8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16490base's changelog is incorrect for 4.13.0.02019-07-07T18:00:10ZRyan Scottbase's changelog is incorrect for 4.13.0.0`base-4.13.0.0` (which will be bundled with GHC 8.8) features a change to `Fixed`'s `Show` instance (see !41). However, `base`'s changelog incorrectly claims that this change will debut in `4.12.0.0`, not `4.13.0.0`.`base-4.13.0.0` (which will be bundled with GHC 8.8) features a change to `Fixed`'s `Show` instance (see !41). However, `base`'s changelog incorrectly claims that this change will debut in `4.12.0.0`, not `4.13.0.0`.8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16398Missing documentation in Windows bindist tarball2019-09-12T22:55:30ZBen GamariMissing documentation in Windows bindist tarballTakenobu noticed the following omissions from the 8.6.4 bindist tarball:
> Perhaps you may know, but the following html documents are not included in
> the windows tarball \[1\]:
>
> - doc/html/index.html
> - doc/html/users_guide/index....Takenobu noticed the following omissions from the 8.6.4 bindist tarball:
> Perhaps you may know, but the following html documents are not included in
> the windows tarball \[1\]:
>
> - doc/html/index.html
> - doc/html/users_guide/index.html
> - doc/html/libraries/index.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Missing documentation in Windows bindist tarball","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Takenobu noticed the following omissions from the 8.6.4 bindist tarball:\r\n\r\n> Perhaps you may know, but the following html documents are not included in\r\n> the windows tarball [1]:\r\n>\r\n> * doc/html/index.html\r\n> * doc/html/users_guide/index.html\r\n> * doc/html/libraries/index.html\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16964Documentation of RuntimeRep is wrong about 64-bit integer reps2022-02-12T03:28:41ZÖmer Sinan AğacanDocumentation of RuntimeRep is wrong about 64-bit integer repsDocumentation of `Int64Rep` and `Word64Rep` currently have the note "on 32-bit only" which seems wrong. Here's an example (this is on a 64-bit system):
```
~ $ cat Main.hs
{-# LANGUAGE TypeApplications, MagicHash #-}
import Type.Reflec...Documentation of `Int64Rep` and `Word64Rep` currently have the note "on 32-bit only" which seems wrong. Here's an example (this is on a 64-bit system):
```
~ $ cat Main.hs
{-# LANGUAGE TypeApplications, MagicHash #-}
import Type.Reflection
import GHC.Types
import GHC.Prim
import Data.Int
main = do
print (splitApps (typeRepKind (typeRep @Int64#)))
print (splitApps (typeRepKind (typeRep @Int#)))
~ $ ghc Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
~ $ ./Main
(TYPE,['Int64Rep])
(TYPE,['IntRep])
```
The documentation seems to suggest that `Int64Rep` should only be used on 32-bit systems, and we should get `IntRep` for `Int64#` on 64-bit.
[(Link to `RuntimeRep`)](https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Exts.html#t:RuntimeRep)
(The same comments exist in GHC HEAD source tree too)
(cc @rae)8.8.1Carter SchonwaldJohn EricsonCarter Schonwaldhttps://gitlab.haskell.org/ghc/ghc/-/issues/15296Sentence is about Complex type but mentions Simple constructor2019-07-07T18:13:23ZSasha Bogicevicsasa.bogicevic@pm.meSentence is about Complex type but mentions Simple constructorThere is a mistype in one of the sentences regarding Roles in the documentation :
https://ghc.readthedocs.io/en/latest/glasgow_exts.html\#nominal-representational-and-phantom
```
Here are some examples:
data Simple a = MkSimple a ...There is a mistype in one of the sentences regarding Roles in the documentation :
https://ghc.readthedocs.io/en/latest/glasgow_exts.html\#nominal-representational-and-phantom
```
Here are some examples:
data Simple a = MkSimple a -- a has role representational
type family F
type instance F Int = Bool
type instance F Age = Char
data Complex a = MkComplex (F a) -- a has role nominal
data Phant a = MkPhant Bool -- a has role phantom
```
The type Simple has its parameter at role representational, which is generally the most common case. Simple Age would have the same representation as Simple Int. The type Complex, on the other hand, has its parameter at role nominal, because Simple Age and Simple Int are not the same. Lastly, Phant Age and Phant Bool have the same representation, even though Age and Bool are unrelated.
The wrong sentence is `The type Complex, on the other hand, has its parameter at role nominal, because Simple Age and Simple Int are not the same. `
<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":"Sentence is about Complex type but mentions Simple constructor","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":"There is a mistype in one of the sentences regarding Roles in the documentation :\r\nhttps://ghc.readthedocs.io/en/latest/glasgow_exts.html#nominal-representational-and-phantom\r\n\r\n{{{\r\nHere are some examples:\r\n\r\ndata Simple a = MkSimple a -- a has role representational\r\n\r\ntype family F\r\ntype instance F Int = Bool\r\ntype instance F Age = Char\r\n\r\ndata Complex a = MkComplex (F a) -- a has role nominal\r\n\r\ndata Phant a = MkPhant Bool -- a has role phantom\r\n}}}\r\nThe type Simple has its parameter at role representational, which is generally the most common case. Simple Age would have the same representation as Simple Int. The type Complex, on the other hand, has its parameter at role nominal, because Simple Age and Simple Int are not the same. Lastly, Phant Age and Phant Bool have the same representation, even though Age and Bool are unrelated.\r\n\r\n\r\nThe wrong sentence is `The type Complex, on the other hand, has its parameter at role nominal, because Simple Age and Simple Int are not the same. `\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Sasha Bogicevicsasa.bogicevic@pm.meSasha Bogicevicsasa.bogicevic@pm.mehttps://gitlab.haskell.org/ghc/ghc/-/issues/15189Avoid word "transformer" in the documentation of ST2019-07-07T18:13:52ZArtem PelenitsynAvoid word "transformer" in the documentation of STI'm unhappy about the current wording in the documentation of the ST module in base. Let me explain why.
Some time ago, as a novice, I struggled to get the difference between three monad-related concepts:
1. The State monad.
1. The Sta...I'm unhappy about the current wording in the documentation of the ST module in base. Let me explain why.
Some time ago, as a novice, I struggled to get the difference between three monad-related concepts:
1. The State monad.
1. The StateT monad transformer.
1. The ST monad.
Current [documentation for ST](http://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Monad-ST.html) says that "ST" stands for state transformer (see everywhere except for the introduction paragraph). While this follows original 1994 paper "Lazy Functional State Threads", I find this confusing after the adoption of term "(monad) transformer" due to 1995 paper "Functional Programming with Overloading and Higher-Order Polymorphism". Note that ST paper predates MT one.
At the same time, the 1994 paper itself (in the title) and some current tutorials, [like the one at HaskelWiki](https://wiki.haskell.org/Monad/ST), use the word "thread" to describe what's going on, avoiding discussion of spelling of ST.
As the bottom line, I think, it would be helpful, especially for a novice, to avoid the word "transformer" in the documentation of ST module.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Avoid word \"transformer\" in the documentation of ST","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I'm unhappy about the current wording in the documentation of the ST module in base. Let me explain why.\r\n\r\nSome time ago, as a novice, I struggled to get the difference between three monad-related concepts:\r\n\r\n1. The State monad.\r\n2. The StateT monad transformer.\r\n3. The ST monad.\r\n\r\nCurrent [http://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Monad-ST.html documentation for ST] says that \"ST\" stands for state transformer (see everywhere except for the introduction paragraph). While this follows original 1994 paper \"Lazy Functional State Threads\", I find this confusing after the adoption of term \"(monad) transformer\" due to 1995 paper \"Functional Programming with Overloading and Higher-Order Polymorphism\". Note that ST paper predates MT one. \r\n\r\nAt the same time, the 1994 paper itself (in the title) and some current tutorials, [https://wiki.haskell.org/Monad/ST like the one at HaskelWiki], use the word \"thread\" to describe what's going on, avoiding discussion of spelling of ST. \r\n\r\nAs the bottom line, I think, it would be helpful, especially for a novice, to avoid the word \"transformer\" in the documentation of ST module.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Artem PelenitsynArtem Pelenitsynhttps://gitlab.haskell.org/ghc/ghc/-/issues/4861Documentation for base does not include special items2019-07-07T18:58:10ZNeil MitchellDocumentation for base does not include special itemsThe documentation for base does not include tuples, lists or arrow. I realise these are special in Haskell, but it seems a shame they aren't documented.
For tuples, the documentation for base doesn't include them in either Prelude or Da...The documentation for base does not include tuples, lists or arrow. I realise these are special in Haskell, but it seems a shame they aren't documented.
For tuples, the documentation for base doesn't include them in either Prelude or Data.Tuple, but the documentation for ghc-prim includes them in GHC.Unit and GHC.Tuple. I think the lack of documentation for tuple types is a bug, since it would be relatively easy for them to be documented, and does make the documentation more complete.
For lists (\[\], (:)), there is no documentation in either base or ghc-prim. It would be nice if they were documented in Prelude and Data.List, but not if it was too much effort (I can imagine that Haddock can't accept list definitions).
For the arrow type -\>, it's unclear if it can reasonably be documented, so it might be worth thinking about but probably not bothering to document.
The reason I'm interested in ensuring complete documentation is that Hoogle currently doesn't know about tuple constructors in the base library, but it does know about them in ghc-prim, which seems wrong.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Documentation for base does not include special items","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"The documentation for base does not include tuples, lists or arrow. I realise these are special in Haskell, but it seems a shame they aren't documented.\r\n\r\nFor tuples, the documentation for base doesn't include them in either Prelude or Data.Tuple, but the documentation for ghc-prim includes them in GHC.Unit and GHC.Tuple. I think the lack of documentation for tuple types is a bug, since it would be relatively easy for them to be documented, and does make the documentation more complete.\r\n\r\nFor lists ([], (:)), there is no documentation in either base or ghc-prim. It would be nice if they were documented in Prelude and Data.List, but not if it was too much effort (I can imagine that Haddock can't accept list definitions).\r\n\r\nFor the arrow type ->, it's unclear if it can reasonably be documented, so it might be worth thinking about but probably not bothering to document.\r\n\r\nThe reason I'm interested in ensuring complete documentation is that Hoogle currently doesn't know about tuple constructors in the base library, but it does know about them in ghc-prim, which seems wrong.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Edward KmettEdward Kmett