[GHC] #8894: Clean up `Coercible` plumbing
#8894: Clean up `Coercible` plumbing ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, the way `Coercible` is exported (with an data type in `GHC.Types` and a built-in !TyCon exported in `GHC.Prim`) works, but is confusing and should be cleaned up. Probably by exporting it directly from `GHC.Types`. Care needs to be taken that ghci and haddock display the data from modified built-in !TyCon; when I tried that a while ago it was displayed as a regular data type by one of them. If that is still the case and I didn't just do a mistake back then, this probably needs to be understood and fixed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8894 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8894: Clean up `Coercible` plumbing
-------------------------------------+------------------------------------
Reporter: nomeata | Owner:
Type: task | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.9
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+------------------------------------
Comment (by Joachim Breitner
#8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Just gave it a shot, and indeed, the generated `libraries/ghc-prim/dist- install/doc/html/ghc-prim/GHC-Types.html#t:Coercible` shows `data Coercible a b` instead of `class Coercible a b`. GHCi gives the correct information upon `:browse GHC.Types`. Interestingly, `libraries/base/dist-install/doc/html/base/Data- Coerce.html` is correct. Since that is the official location for `Coercible`, I’ll actually push the change; this way someone who knows haddock can have a look (the changes affects three repositories, so having it as a branch is somewhat overkill). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8894#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8894: Clean up `Coercible` plumbing
-------------------------------------+------------------------------------
Reporter: nomeata | Owner:
Type: task | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.9
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+------------------------------------
Comment (by Joachim Breitner
#8894: Clean up `Coercible` plumbing
-------------------------------------+------------------------------------
Reporter: nomeata | Owner:
Type: task | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.9
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+------------------------------------
Comment (by Joachim Breitner
#8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed * related: => #8904 Comment: Ok, pushed. The haddock/GHC API issue is at #8904. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8894#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Comment (by simonpj): Thanks for doing this. I think it's clearly better. Actually I think we can go two steps better still. * Suppose the declaration of `Coercible` in `GHC.Types` is actually {{{ class Coercible a b }}} Then, when compiling `GHC.Types`, the code we produce for the declaration will still include code for the data constructor of the dictionary (with no value fields), although with a different name, built with `mkClassDataConOcc`. But that is fine, provided we adjust the `coercibleDataConName` in `TysWiredIn` to match; and that would probably be a good piece of consistency anyway. * Once that is done, we can declare `coerce` in `GHC.Types` rather than `GHC.Prim`: {{{ coerce :: Coercible a b => a -> b coerce = error "You should not be calling me" }}} * And it might be possible to move both these definitions to `Data.Coerce` which would be better still. Haddock will display the right result for every module, and the documentation will all be in one place in `Data.Coerce`. All this should work because `Coercible` and `coerce` are "wired-in" things, and so they are never written to an interface file. Importing modules just use GHC's built-in knowledge of them. It's fine provided the code generated by compiling the definitions matches the wired-in knowledge. Does that make sense? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8894#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Changes (by nomeata): * status: closed => new * resolution: fixed => Comment:
All this should work because Coercible and coerce are "wired-in" things, and so they are never written to an interface file
Woudn’t they get written to `GHC.Types` hi interface? Also, would the info table for `MkCoerce` (or however it would be called then) without fields match ours? This requires knowledge of the RTS that I don’t have, so I felt safer with this approach, but if you think it might work, it’s worth a try. (I’d be tempted to put them in a module `GHC.Coerce` in `ghc-prim` and have `Data.Coerce` in `base` re-export it, to slowly work towards having no magic in base, but that is a minor point.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8894#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Changes (by nomeata): * owner: => nomeata -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8894#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Comment (by simonpj): No, wired-in things are never written to any interface file. GHC already knows all about them, so there's not point in serialising them. Yes, the data constructor would match. (Of course that requires a `Note`.) By declaring a data type and using it as a class we are already being naughty in a different way, so it's really no worse. I have not thought about "no magic in base", although I have not objection. If that's the route you go, be sure to document it as the reason (in `GHC.Coerce`) so that we know in five years time. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8894#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Comment (by simonpj): I'm getting this: {{{ typecheck/should_fail TcCoercibleFail [stderr mismatch] (normal) typecheck/should_fail TcCoercibleFail2 [stderr mismatch] (normal) typecheck/should_fail TcCoercibleFail3 [stderr mismatch] (normal) }}} The error is {{{ +TcCoercibleFail.hs:3:26: + Module ‘GHC.Prim’ does not export ‘Coercible’ }}} And indeed `GHC.Prim` doesn't export `Coercible` any more. Did you validate? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8894#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8894: Clean up `Coercible` plumbing
-------------------------------------+------------------------------------
Reporter: nomeata | Owner: nomeata
Type: task | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.9
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets: #8904
-------------------------------------+------------------------------------
Comment (by Joachim Breitner
#8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Comment (by nomeata): No, I was a bad boy and lazy and thought I thought of everyting. Fixing the test cases to use the proper import point `Data.Coerce`. I would have noticed myself quicker if CI was useful at the moment, but there are other failures there waiting to be fixed for a few days now :-( -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8894#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8904 Test Case: | Blocking: | Differential Revisions: Phab:D300 | -------------------------------------+------------------------------------- Changes (by nomeata): * differential: => Phab:D300 Comment: I gave it a shot (Phab:D300), but I get {{{ HC [stage 1] utils/dll-split/dist-install/build/tmp/dll-split /home/jojo/build/haskell/ghc-validate/libraries/base/dist-install/build /libHSbase_ESD4aQEEWwsHtYJVc1BwtJ-ghc7.9.20141002.so: undefined reference to `base_DataziCoerce_DZCCoercible_con_info' }}} Is there really a data constructor being generated for an empty class? (Feel free to continue discussing this on Phab:D300). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8894#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8904 Test Case: | Blocking: | Differential Revisions: Phab:D300 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => wontfix Comment: SPJ says at https://phabricator.haskell.org/D300#15193 that we probably won’t need this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8894#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC