RE: [commit: ghc] master: Module reexports, fixing #8407. (7f5c1086)
Edward
Great stuff. Is this documented somewhere, notably in
http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html
for GHC, and somewhere in Cabal?
And perhaps somewhere on the wiki
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Packages
Thanks
Simon
| -Original Message-
| From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of
| g...@git.haskell.org
| Sent: 26 July 2014 02:08
| To: ghc-comm...@haskell.org
| Subject: [commit: ghc] master: Module reexports, fixing #8407.
| (7f5c1086)
|
| Repository : ssh://g...@git.haskell.org/ghc
|
| On branch : master
| Link :
| http://ghc.haskell.org/trac/ghc/changeset/7f5c10864e7c26b90c7ff4ed09d00
| c8a09aa4349/ghc
|
| ---
|
| commit 7f5c10864e7c26b90c7ff4ed09d00c8a09aa4349
| Author: Edward Z. Yang ezy...@cs.stanford.edu
| Date: Fri Jul 4 17:01:08 2014 +0100
|
| Module reexports, fixing #8407.
|
| The general approach is to add a new field to the package database,
| reexported-modules, which considered by the module finder as
| possible
| module declarations. Unlike declaring stub module files, multiple
| reexports of the same physical package at the same name do not
| result in an ambiguous import.
|
| Has submodule updates for Cabal and haddock.
|
| NB: When a reexport renames a module, that renaming is *not*
| accessible
| from inside the package. This is not so much a deliberate design
| choice
| as for implementation expediency (reexport resolution happens only
| when
| a package is in the package database.)
|
| TODO: Error handling when there are duplicate reexports/etc is not
| very
| well tested.
|
| Signed-off-by: Edward Z. Yang ezy...@cs.stanford.edu
|
| Conflicts:
| compiler/main/HscTypes.lhs
| testsuite/.gitignore
| utils/haddock
|
|
| ---
|
| 7f5c10864e7c26b90c7ff4ed09d00c8a09aa4349
| compiler/main/DynFlags.hs | 1 +
| compiler/main/Finder.lhs | 25 +++--
| compiler/main/GHC.hs | 12 ++-
| compiler/main/HscTypes.lhs | 6 +-
| compiler/main/PackageConfig.hs | 4 +
| compiler/main/Packages.lhs | 109
| -
| ghc/InteractiveUI.hs | 8 +-
| libraries/Cabal| 2 +-
| .../Distribution/InstalledPackageInfo/Binary.hs| 8 ++
| testsuite/.gitignore | 8 ++
| testsuite/tests/cabal/Makefile | 15 +++
| testsuite/tests/cabal/all.T| 6 ++
| testsuite/tests/cabal/cabal05/Makefile | 69 +
| .../{driver/T3007/A = cabal/cabal05}/Setup.hs | 0
| testsuite/tests/cabal/{cabal03 = cabal05}/all.T | 4 +-
| .../tests/cabal/cabal05/p/LICENSE | 0
| testsuite/tests/cabal/cabal05/p/P.hs | 3 +
| testsuite/tests/cabal/cabal05/p/P2.hs | 1 +
| .../{driver/T3007/A = cabal/cabal05/p}/Setup.hs | 0
| testsuite/tests/cabal/cabal05/p/p.cabal| 11 +++
| .../tests/cabal/cabal05/q/LICENSE | 0
| testsuite/tests/cabal/cabal05/q/Q.hs | 4 +
| .../{driver/T3007/A = cabal/cabal05/q}/Setup.hs | 0
| testsuite/tests/cabal/cabal05/q/q.cabal| 29 ++
| .../tests/cabal/cabal05/r/LICENSE | 0
| testsuite/tests/cabal/cabal05/r/R.hs | 11 +++
| .../{driver/T3007/A = cabal/cabal05/r}/Setup.hs | 0
| testsuite/tests/cabal/cabal05/r/r.cabal| 32 ++
| .../tests/cabal/cabal05/s/LICENSE | 0
| testsuite/tests/cabal/cabal05/s/S.hs | 18
| .../{driver/T3007/A = cabal/cabal05/s}/Setup.hs | 0
| testsuite/tests/cabal/cabal05/s/s.cabal| 11 +++
| testsuite/tests/cabal/ghcpkg07.stdout | 11 +++
| .../{test4.pkg = recache_reexport_db/a.conf} | 20 ++--
| testsuite/tests/cabal/{test4.pkg = test7a.pkg}| 20 ++--
| testsuite/tests/cabal/test7b.pkg | 17
| utils/ghc-cabal/ghc-cabal.cabal| 3 +-
| utils/ghc-pkg/Main.hs | 55 ++-
| utils/ghc-pkg/ghc-pkg.cabal| 4 +-
| utils/ghctags/ghctags.cabal| 3 +-
| utils/haddock | 2 +-
| 41 files changed, 453 insertions(+), 79 deletions(-)
|
| Diff suppressed because of size. To see it, use:
|
| git diff-tree --root --patch-with-stat --no-color --find-copies-
| harder --ignore-space-at-eol --cc
| 7f5c10864e7c26b90c7ff4ed09d00c8a09aa4349
| ___
| ghc-commits mailing list
|
RE: Broken Data.Data instances
I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used to be built this way before I convinced the authors to switch to safer versions of Data. Using virtual smart constructors like we do now in containers and Text where needed can be used to preserve internal invariants, etc. If the “hand grenades” are the PostTcTypes, etc, then I can explain why they are there. There simply is no sensible type you can put before the type checker runs. For example one of the constructors in HsExpr is | HsMultiIf PostTcType [LGRHS id (LHsExpr id)] After type checking we know what type the thing has, but before we have no clue. We could get around this by saying type PostTcType = Maybe TcType but that would mean that every post-typechecking consumer would need a redundant pattern-match on a Just that would always succeed. It’s nothing deeper than that. Adding Maybes everywhere would be possible, just clunky. However we now have type functions, and HsExpr is parameterised by an ‘id’ parameter, which changes from RdrName (after parsing) to Name (after renaming) to Id (after typechecking). So we could do this: | HsMultiIf (PostTcType id) [LGRHS id (LHsExpr id)] and define PostTcType as a closed type family thus type family PostTcType a where PostTcType Id = TcType PostTcType other = () That would be better than filling it with bottoms. But it might not help with generic programming, because there’d be a component whose type wasn’t fixed. I have no idea how generics and type functions interact. Simon From: Edward Kmett [mailto:ekm...@gmail.com] Sent: 27 July 2014 18:27 To: p.k.f.holzensp...@utwente.nl Cc: alan.z...@gmail.com; Simon Peyton Jones; ghc-devs Subject: Re: Broken Data.Data instances Philip, Alan, If you need a hand, I'm happy to pitch in guidance. I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used to be built this way before I convinced the authors to switch to safer versions of Data. Using virtual smart constructors like we do now in containers and Text where needed can be used to preserve internal invariants, etc. This works far better for users of the API than just randomly throwing them a live hand grenade. As I recall, these little grenades in generic programming over the GHC API have been a constant source of pain for libraries like haddock. Simon, It seems to me that regarding circular data structures, nothing prevents you from walking a circular data structure with Data.Data. You can generate a new one productively that looks just like the old with the contents swapped out, it is indistinguishable to an observer if the fixed point is lost, and a clever observer can use observable sharing to get it back, supposing that they are allowed to try. Alternately, we could use the 'virtual constructor' trick there to break the cycle and reintroduce it, but I'm less enthusiastic about that idea, even if it is simpler in many ways. -Edward On Sun, Jul 27, 2014 at 10:17 AM, p.k.f.holzensp...@utwente.nlmailto:p.k.f.holzensp...@utwente.nl wrote: Alan, In that case, let's have a short feedback-loop between the two of us. It seems many of these files (Name.lhs, for example) are really stable through the repo-history. It would be nice to have one bigger refactoring all in one go (some of the code could use a polish, a lot of code seems removable). Regards, Philip Van: Alan Kim Zimmerman [alan.z...@gmail.commailto:alan.z...@gmail.com] Verzonden: vrijdag 25 juli 2014 13:44 Aan: Simon Peyton Jones CC: Holzenspies, P.K.F. (EWI); ghc-devs@haskell.orgmailto:ghc-devs@haskell.org Onderwerp: Re: Broken Data.Data instances By the way, I would be happy to attempt this task, if the concept is viable. On Thu, Jul 24, 2014 at 11:23 PM, Alan Kim Zimmerman alan.z...@gmail.commailto:alan.z...@gmail.com wrote: While we are talking about fixing traversals, how about getting rid of the phase specific panic initialisers for placeHolderType, placeHolderKind and friends? In order to safely traverse with SYB, the following needs to be inserted into all the SYB schemes (see https://github.com/alanz/HaRe/blob/master/src/Language/Haskell/Refact/Utils/GhcUtils.hs) -- Check the Typeable items checkItemStage1 :: (Typeable a) = SYB.Stage - a - Bool checkItemStage1 stage x = (const False `SYB.extQ` postTcType `SYB.extQ` fixity `SYB.extQ` nameSet) x where nameSet = const (stage `elem` [SYB.Parser,SYB.TypeChecker]) :: GHC.NameSet - Bool postTcType = const (stage SYB.TypeChecker ) :: GHC.PostTcType- Bool fixity = const (stage SYB.Renamer ) :: GHC.Fixity- Bool And in addition HsCmdTop and ParStmtBlock are initialised with explicit 'undefined values. Perhaps use an initialiser that can have its panic turned off when
Re: Broken Data.Data instances
What about creating a specific type with a single constructor for the not relevant to this phase type to be used instead of () above? That would also clearly document what was going on. Alan On Mon, Jul 28, 2014 at 9:14 AM, Simon Peyton Jones simo...@microsoft.com wrote: I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used to be built this way before I convinced the authors to switch to safer versions of Data. Using virtual smart constructors like we do now in containers and Text where needed can be used to preserve internal invariants, etc. If the “hand grenades” are the PostTcTypes, etc, then I can explain why they are there. There simply is no sensible type you can put before the type checker runs. For example one of the constructors in HsExpr is | HsMultiIf PostTcType [LGRHS id (LHsExpr id)] After type checking we know what type the thing has, but before we have no clue. We could get around this by saying type PostTcType = Maybe TcType but that would mean that every post-typechecking consumer would need a redundant pattern-match on a Just that would always succeed. It’s nothing deeper than that. Adding Maybes everywhere would be possible, just clunky. However we now have type functions, and HsExpr is parameterised by an ‘id’ parameter, which changes from RdrName (after parsing) to Name (after renaming) to Id (after typechecking). So we could do this: | HsMultiIf (PostTcType id) [LGRHS id (LHsExpr id)] and define PostTcType as a closed type family thus type family PostTcType a where PostTcType Id = TcType PostTcType other = () That would be better than filling it with bottoms. But it might not help with generic programming, because there’d be a component whose type wasn’t fixed. I have no idea how generics and type functions interact. Simon *From:* Edward Kmett [mailto:ekm...@gmail.com] *Sent:* 27 July 2014 18:27 *To:* p.k.f.holzensp...@utwente.nl *Cc:* alan.z...@gmail.com; Simon Peyton Jones; ghc-devs *Subject:* Re: Broken Data.Data instances Philip, Alan, If you need a hand, I'm happy to pitch in guidance. I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used to be built this way before I convinced the authors to switch to safer versions of Data. Using virtual smart constructors like we do now in containers and Text where needed can be used to preserve internal invariants, etc. This works far better for users of the API than just randomly throwing them a live hand grenade. As I recall, these little grenades in generic programming over the GHC API have been a constant source of pain for libraries like haddock. Simon, It seems to me that regarding circular data structures, nothing prevents you from walking a circular data structure with Data.Data. You can generate a new one productively that looks just like the old with the contents swapped out, it is indistinguishable to an observer if the fixed point is lost, and a clever observer can use observable sharing to get it back, supposing that they are allowed to try. Alternately, we could use the 'virtual constructor' trick there to break the cycle and reintroduce it, but I'm less enthusiastic about that idea, even if it is simpler in many ways. -Edward On Sun, Jul 27, 2014 at 10:17 AM, p.k.f.holzensp...@utwente.nl wrote: Alan, In that case, let's have a short feedback-loop between the two of us. It seems many of these files (Name.lhs, for example) are really stable through the repo-history. It would be nice to have one bigger refactoring all in one go (some of the code could use a polish, a lot of code seems removable). Regards, Philip -- *Van:* Alan Kim Zimmerman [alan.z...@gmail.com] *Verzonden:* vrijdag 25 juli 2014 13:44 *Aan:* Simon Peyton Jones *CC:* Holzenspies, P.K.F. (EWI); ghc-devs@haskell.org *Onderwerp:* Re: Broken Data.Data instances By the way, I would be happy to attempt this task, if the concept is viable. On Thu, Jul 24, 2014 at 11:23 PM, Alan Kim Zimmerman alan.z...@gmail.com wrote: While we are talking about fixing traversals, how about getting rid of the phase specific panic initialisers for placeHolderType, placeHolderKind and friends? In order to safely traverse with SYB, the following needs to be inserted into all the SYB schemes (see https://github.com/alanz/HaRe/blob/master/src/Language/Haskell/Refact/Utils/GhcUtils.hs ) -- Check the Typeable items checkItemStage1 :: (Typeable a) = SYB.Stage - a - Bool checkItemStage1 stage x = (const False `SYB.extQ` postTcType `SYB.extQ` fixity `SYB.extQ` nameSet) x where nameSet = const (stage `elem` [SYB.Parser,SYB.TypeChecker]) :: GHC.NameSet - Bool postTcType = const (stage SYB.TypeChecker
RE: Broken Data.Data instances
I always read the () as “there’s nothing meaningful to stick in here, but I have to stick in something” so I don’t necessarily want the WrongPhase-thing. There is very old commentary stating it would be lovely if someone could expose the PostTcType as a parameter of the AST-types, but that there are so many types and constructors, that it’s a boring chore to do. Actually, I was hoping haRe would come up to speed to be able to do this. That being said, I think Simon’s idea to turn PostTcType into a type-family is a better way altogether; it also documents intent, i.e. () may not say so much, but PostTcType RdrName says quite a lot. Simon commented that a lot of the internal structures aren’t trees, but cyclic graphs, e.g. the TyCon for Maybe references the DataCons for Just and Nothing, which again refer to the TyCon for Maybe. From: Alan Kim Zimmerman [mailto:alan.z...@gmail.com] Sent: maandag 28 juli 2014 11:14 To: Simon Peyton Jones Cc: Edward Kmett; Holzenspies, P.K.F. (EWI); ghc-devs Subject: Re: Broken Data.Data instances I have made a conceptual example of this here http://lpaste.net/108262 Alan On Mon, Jul 28, 2014 at 9:50 AM, Alan Kim Zimmerman alan.z...@gmail.commailto:alan.z...@gmail.com wrote: What about creating a specific type with a single constructor for the not relevant to this phase type to be used instead of () above? That would also clearly document what was going on. Alan On Mon, Jul 28, 2014 at 9:14 AM, Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used to be built this way before I convinced the authors to switch to safer versions of Data. Using virtual smart constructors like we do now in containers and Text where needed can be used to preserve internal invariants, etc. If the “hand grenades” are the PostTcTypes, etc, then I can explain why they are there. There simply is no sensible type you can put before the type checker runs. For example one of the constructors in HsExpr is | HsMultiIf PostTcType [LGRHS id (LHsExpr id)] After type checking we know what type the thing has, but before we have no clue. We could get around this by saying type PostTcType = Maybe TcType but that would mean that every post-typechecking consumer would need a redundant pattern-match on a Just that would always succeed. It’s nothing deeper than that. Adding Maybes everywhere would be possible, just clunky. However we now have type functions, and HsExpr is parameterised by an ‘id’ parameter, which changes from RdrName (after parsing) to Name (after renaming) to Id (after typechecking). So we could do this: | HsMultiIf (PostTcType id) [LGRHS id (LHsExpr id)] and define PostTcType as a closed type family thus type family PostTcType a where PostTcType Id = TcType PostTcType other = () That would be better than filling it with bottoms. But it might not help with generic programming, because there’d be a component whose type wasn’t fixed. I have no idea how generics and type functions interact. Simon From: Edward Kmett [mailto:ekm...@gmail.commailto:ekm...@gmail.com] Sent: 27 July 2014 18:27 To: p.k.f.holzensp...@utwente.nlmailto:p.k.f.holzensp...@utwente.nl Cc: alan.z...@gmail.commailto:alan.z...@gmail.com; Simon Peyton Jones; ghc-devs Subject: Re: Broken Data.Data instances Philip, Alan, If you need a hand, I'm happy to pitch in guidance. I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used to be built this way before I convinced the authors to switch to safer versions of Data. Using virtual smart constructors like we do now in containers and Text where needed can be used to preserve internal invariants, etc. This works far better for users of the API than just randomly throwing them a live hand grenade. As I recall, these little grenades in generic programming over the GHC API have been a constant source of pain for libraries like haddock. Simon, It seems to me that regarding circular data structures, nothing prevents you from walking a circular data structure with Data.Data. You can generate a new one productively that looks just like the old with the contents swapped out, it is indistinguishable to an observer if the fixed point is lost, and a clever observer can use observable sharing to get it back, supposing that they are allowed to try. Alternately, we could use the 'virtual constructor' trick there to break the cycle and reintroduce it, but I'm less enthusiastic about that idea, even if it is simpler in many ways. -Edward On Sun, Jul 27, 2014 at 10:17 AM, p.k.f.holzensp...@utwente.nlmailto:p.k.f.holzensp...@utwente.nl wrote: Alan, In that case, let's have a short feedback-loop between the two of us. It seems many of these files (Name.lhs, for example) are really stable through the
RE: Broken Data.Data instances
Sorry about that… I’m having it out with my terminal server and the server seems to be winning. Here’s another go: I always read the () as “there’s nothing meaningful to stick in here, but I have to stick in something” so I don’t necessarily want the WrongPhase-thing. There is very old commentary stating it would be lovely if someone could expose the PostTcType as a parameter of the AST-types, but that there are so many types and constructors, that it’s a boring chore to do. Actually, I was hoping haRe would come up to speed to be able to do this. That being said, I think Simon’s idea to turn PostTcType into a type-family is a better way altogether; it also documents intent, i.e. () may not say so much, but PostTcType RdrName says quite a lot. Simon commented that a lot of the internal structures aren’t trees, but cyclic graphs, e.g. the TyCon for Maybe references the DataCons for Just and Nothing, which again refer to the TyCon for Maybe. I was wondering whether it would be possible to make stateful lenses for this. Of course, for specific cases, we could do this, but I wonder if it is also possible to have lenses remember the things they visited and not visit them twice. Any ideas on this, Edward? Regards, Philip From: Alan Kim Zimmerman [mailto:alan.z...@gmail.com] Sent: maandag 28 juli 2014 11:14 To: Simon Peyton Jones Cc: Edward Kmett; Holzenspies, P.K.F. (EWI); ghc-devs Subject: Re: Broken Data.Data instances I have made a conceptual example of this here http://lpaste.net/108262 Alan On Mon, Jul 28, 2014 at 9:50 AM, Alan Kim Zimmerman alan.z...@gmail.commailto:alan.z...@gmail.com wrote: What about creating a specific type with a single constructor for the not relevant to this phase type to be used instead of () above? That would also clearly document what was going on. Alan On Mon, Jul 28, 2014 at 9:14 AM, Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used to be built this way before I convinced the authors to switch to safer versions of Data. Using virtual smart constructors like we do now in containers and Text where needed can be used to preserve internal invariants, etc. If the “hand grenades” are the PostTcTypes, etc, then I can explain why they are there. There simply is no sensible type you can put before the type checker runs. For example one of the constructors in HsExpr is | HsMultiIf PostTcType [LGRHS id (LHsExpr id)] After type checking we know what type the thing has, but before we have no clue. We could get around this by saying type PostTcType = Maybe TcType but that would mean that every post-typechecking consumer would need a redundant pattern-match on a Just that would always succeed. It’s nothing deeper than that. Adding Maybes everywhere would be possible, just clunky. However we now have type functions, and HsExpr is parameterised by an ‘id’ parameter, which changes from RdrName (after parsing) to Name (after renaming) to Id (after typechecking). So we could do this: | HsMultiIf (PostTcType id) [LGRHS id (LHsExpr id)] and define PostTcType as a closed type family thus type family PostTcType a where PostTcType Id = TcType PostTcType other = () That would be better than filling it with bottoms. But it might not help with generic programming, because there’d be a component whose type wasn’t fixed. I have no idea how generics and type functions interact. Simon From: Edward Kmett [mailto:ekm...@gmail.commailto:ekm...@gmail.com] Sent: 27 July 2014 18:27 To: p.k.f.holzensp...@utwente.nlmailto:p.k.f.holzensp...@utwente.nl Cc: alan.z...@gmail.commailto:alan.z...@gmail.com; Simon Peyton Jones; ghc-devs Subject: Re: Broken Data.Data instances Philip, Alan, If you need a hand, I'm happy to pitch in guidance. I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used to be built this way before I convinced the authors to switch to safer versions of Data. Using virtual smart constructors like we do now in containers and Text where needed can be used to preserve internal invariants, etc. This works far better for users of the API than just randomly throwing them a live hand grenade. As I recall, these little grenades in generic programming over the GHC API have been a constant source of pain for libraries like haddock. Simon, It seems to me that regarding circular data structures, nothing prevents you from walking a circular data structure with Data.Data. You can generate a new one productively that looks just like the old with the contents swapped out, it is indistinguishable to an observer if the fixed point is lost, and a clever observer can use observable sharing to get it back, supposing that they are allowed to try. Alternately, we could use the 'virtual constructor' trick there
RE: [commit: ghc] master: Module reexports, fixing #8407. (7f5c1086)
Excerpts from Simon Peyton Jones's message of 2014-07-28 07:45:23 +0100: Great stuff. Is this documented somewhere, notably in http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html for GHC, and somewhere in Cabal? You're right, I should add a line to the installed package specification. We're already documented as far as Cabal is concerned. And perhaps somewhere on the wiki https://ghc.haskell.org/trac/ghc/wiki/Commentary/Packages It's not on that page, but it is here https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Packages#Reexportedmodules Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: [commit: ghc] master: Module reexports, fixing #8407. (7f5c1086)
Excerpts from Edward Z. Yang's message of 2014-07-28 11:38:43 +0100: You're right, I should add a line to the installed package specification. We're already documented as far as Cabal is concerned. OK, this is done. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Status updates
Hello *, Here are some notes on what I've done in the past week, and what I plan on doing going forward: - First and foremost, I made a bunch of improvements to Phabricator/Trac. Now, most noticeably: 1) Phabricator has a field for GHC trac tickets. You can specify this when you run 'arc diff', and it will appear on the Differential Revision. By default if you run 'arc diff', this field appears at the bottom, below 'Subscribers:'. 2) Phabricator now supports Trac markup syntax - if you say '#7602' in a trac ticket, this turns into a hyperlink with the text Trac #7602 and links to the ticket. 3) The IRC bot on #ghc can now look up Trac tickets for you (this is mostly only relevant to those of us there) - The final piece of this whole story is actually getting Phabricator to *comment* on Trac. This is almost done, but due to the fact I'm writing PHP (and thus have absolutely no idea what I'm doing) the code still seems slightly broken somewhere since it's one of the larger parts of the Phabricator integration. Hopefully I can finish this soon. I will say though - thank you Herbert for helping me figure out the Trac XML/RPC plugin, and getting it working for me! - Another Phabricator related thing: I've begun working on a better Harbormaster build backend - it will actually report failures, support concurrent builds, and give you stderr in log results! Yay! - I took some time to further clean up the Git wiki page following last week, but only made minor progress here. - The patch queue is, in fact, being drained as we speak! I have a whole bunch of incoming patches from contributors running under ./validate as I write this, including some cleanup commits too (to detab/whitespace things). Not all of them, but a good chunk I could fit in that were low-impact and correct. - I have not finished AMP. :( This is quickly going to be my #1 priority before fixing any bugs because at this point, it's holding up other `base` improvements (Edward K, I'm sure, is getting a bit fiddly about this getting done :) This week: - Before fixing *any* new bugs myself, I'm going to finish AMP, because it's a blocker for others including Edward, Simon, and future base improvements. I'm thinking I may just do this before any more Phabricator improvements. - I will hopefully finish the Trac and Phabricator setup soon. at the very least I want to get the comment updates working. I'll probably continue with the build system shenannigans sometime after. - The wiki pages and Git stuff still need more cleanup to streamline them. This will be happening when I get a chance (Herbert already improved some things I touched last week - Thanks!) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Broken Data.Data instances
Dear Alan, I would think you would want to constrain the result, i.e. type family (Data (PostTcType a)) = PostTcType a where … The Data-instance of ‘a’ doesn’t give you much if you have a ‘PostTcType a’. Your point about SYB-recognition of WrongPhase is, of course, a good one ;) Regards, Philip From: Alan Kim Zimmerman [mailto:alan.z...@gmail.com] Sent: maandag 28 juli 2014 14:10 To: Holzenspies, P.K.F. (EWI) Cc: Simon Peyton Jones; Edward Kmett; ghc-devs@haskell.org Subject: Re: Broken Data.Data instances Philip I think the main reason for the WrongPhase thing is to have something that explicitly has a Data and Typeable instance, to allow generic (SYB) traversal. If we can get by without this so much the better. On a related note, is there any way to constrain the 'a' in type family PostTcType a where PostTcType Id= TcType PostTcType other = WrongPhaseTyp to have an instance of Data? I am experimenting with traversals over my earlier paste, and got stuck here (which is the reason the Show instances were commentet out in the original). Alan On Mon, Jul 28, 2014 at 12:30 PM, p.k.f.holzensp...@utwente.nlmailto:p.k.f.holzensp...@utwente.nl wrote: Sorry about that… I’m having it out with my terminal server and the server seems to be winning. Here’s another go: I always read the () as “there’s nothing meaningful to stick in here, but I have to stick in something” so I don’t necessarily want the WrongPhase-thing. There is very old commentary stating it would be lovely if someone could expose the PostTcType as a parameter of the AST-types, but that there are so many types and constructors, that it’s a boring chore to do. Actually, I was hoping haRe would come up to speed to be able to do this. That being said, I think Simon’s idea to turn PostTcType into a type-family is a better way altogether; it also documents intent, i.e. () may not say so much, but PostTcType RdrName says quite a lot. Simon commented that a lot of the internal structures aren’t trees, but cyclic graphs, e.g. the TyCon for Maybe references the DataCons for Just and Nothing, which again refer to the TyCon for Maybe. I was wondering whether it would be possible to make stateful lenses for this. Of course, for specific cases, we could do this, but I wonder if it is also possible to have lenses remember the things they visited and not visit them twice. Any ideas on this, Edward? Regards, Philip From: Alan Kim Zimmerman [mailto:alan.z...@gmail.commailto:alan.z...@gmail.com] Sent: maandag 28 juli 2014 11:14 To: Simon Peyton Jones Cc: Edward Kmett; Holzenspies, P.K.F. (EWI); ghc-devs Subject: Re: Broken Data.Data instances I have made a conceptual example of this here http://lpaste.net/108262 Alan On Mon, Jul 28, 2014 at 9:50 AM, Alan Kim Zimmerman alan.z...@gmail.commailto:alan.z...@gmail.com wrote: What about creating a specific type with a single constructor for the not relevant to this phase type to be used instead of () above? That would also clearly document what was going on. Alan On Mon, Jul 28, 2014 at 9:14 AM, Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used to be built this way before I convinced the authors to switch to safer versions of Data. Using virtual smart constructors like we do now in containers and Text where needed can be used to preserve internal invariants, etc. If the “hand grenades” are the PostTcTypes, etc, then I can explain why they are there. There simply is no sensible type you can put before the type checker runs. For example one of the constructors in HsExpr is | HsMultiIf PostTcType [LGRHS id (LHsExpr id)] After type checking we know what type the thing has, but before we have no clue. We could get around this by saying type PostTcType = Maybe TcType but that would mean that every post-typechecking consumer would need a redundant pattern-match on a Just that would always succeed. It’s nothing deeper than that. Adding Maybes everywhere would be possible, just clunky. However we now have type functions, and HsExpr is parameterised by an ‘id’ parameter, which changes from RdrName (after parsing) to Name (after renaming) to Id (after typechecking). So we could do this: | HsMultiIf (PostTcType id) [LGRHS id (LHsExpr id)] and define PostTcType as a closed type family thus type family PostTcType a where PostTcType Id = TcType PostTcType other = () That would be better than filling it with bottoms. But it might not help with generic programming, because there’d be a component whose type wasn’t fixed. I have no idea how generics and type functions interact. Simon From: Edward Kmett [mailto:ekm...@gmail.commailto:ekm...@gmail.com] Sent: 27 July 2014 18:27 To: p.k.f.holzensp...@utwente.nlmailto:p.k.f.holzensp...@utwente.nl Cc:
Re: Broken Data.Data instances
I already tried that, the syntax does not seem to allow it. I suspect some higher form of sorcery will be required, as alluded to here http://stackoverflow.com/questions/14133121/can-i-constrain-a-type-family Alan On Mon, Jul 28, 2014 at 4:55 PM, p.k.f.holzensp...@utwente.nl wrote: Dear Alan, I would think you would want to constrain the result, i.e. type family (Data (PostTcType a)) = PostTcType a where … The Data-instance of ‘a’ doesn’t give you much if you have a ‘PostTcType a’. Your point about SYB-recognition of WrongPhase is, of course, a good one ;) Regards, Philip *From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com] *Sent:* maandag 28 juli 2014 14:10 *To:* Holzenspies, P.K.F. (EWI) *Cc:* Simon Peyton Jones; Edward Kmett; ghc-devs@haskell.org *Subject:* Re: Broken Data.Data instances Philip I think the main reason for the WrongPhase thing is to have something that explicitly has a Data and Typeable instance, to allow generic (SYB) traversal. If we can get by without this so much the better. On a related note, is there any way to constrain the 'a' in type family PostTcType a where PostTcType Id= TcType PostTcType other = WrongPhaseTyp to have an instance of Data? I am experimenting with traversals over my earlier paste, and got stuck here (which is the reason the Show instances were commentet out in the original). Alan On Mon, Jul 28, 2014 at 12:30 PM, p.k.f.holzensp...@utwente.nl wrote: Sorry about that… I’m having it out with my terminal server and the server seems to be winning. Here’s another go: I always read the () as “there’s nothing meaningful to stick in here, but I have to stick in something” so I don’t necessarily want the WrongPhase-thing. There is very old commentary stating it would be lovely if someone could expose the PostTcType as a parameter of the AST-types, but that there are so many types and constructors, that it’s a boring chore to do. Actually, I was hoping haRe would come up to speed to be able to do this. That being said, I think Simon’s idea to turn PostTcType into a type-family is a better way altogether; it also documents intent, i.e. () may not say so much, but PostTcType RdrName says quite a lot. Simon commented that a lot of the internal structures aren’t trees, but cyclic graphs, e.g. the TyCon for Maybe references the DataCons for Just and Nothing, which again refer to the TyCon for Maybe. I was wondering whether it would be possible to make stateful lenses for this. Of course, for specific cases, we could do this, but I wonder if it is also possible to have lenses remember the things they visited and not visit them twice. Any ideas on this, Edward? Regards, Philip *From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com] *Sent:* maandag 28 juli 2014 11:14 *To:* Simon Peyton Jones *Cc:* Edward Kmett; Holzenspies, P.K.F. (EWI); ghc-devs *Subject:* Re: Broken Data.Data instances I have made a conceptual example of this here http://lpaste.net/108262 Alan On Mon, Jul 28, 2014 at 9:50 AM, Alan Kim Zimmerman alan.z...@gmail.com wrote: What about creating a specific type with a single constructor for the not relevant to this phase type to be used instead of () above? That would also clearly document what was going on. Alan On Mon, Jul 28, 2014 at 9:14 AM, Simon Peyton Jones simo...@microsoft.com wrote: I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used to be built this way before I convinced the authors to switch to safer versions of Data. Using virtual smart constructors like we do now in containers and Text where needed can be used to preserve internal invariants, etc. If the “hand grenades” are the PostTcTypes, etc, then I can explain why they are there. There simply is no sensible type you can put before the type checker runs. For example one of the constructors in HsExpr is | HsMultiIf PostTcType [LGRHS id (LHsExpr id)] After type checking we know what type the thing has, but before we have no clue. We could get around this by saying type PostTcType = Maybe TcType but that would mean that every post-typechecking consumer would need a redundant pattern-match on a Just that would always succeed. It’s nothing deeper than that. Adding Maybes everywhere would be possible, just clunky. However we now have type functions, and HsExpr is parameterised by an ‘id’ parameter, which changes from RdrName (after parsing) to Name (after renaming) to Id (after typechecking). So we could do this: | HsMultiIf (PostTcType id) [LGRHS id (LHsExpr id)] and define PostTcType as a closed type family thus type family PostTcType a where PostTcType Id = TcType PostTcType other = () That would be better than filling it with bottoms. But it might not help with generic
Re: Broken Data.Data instances
FYI I edited the paste at http://lpaste.net/108262 to show the problem On Mon, Jul 28, 2014 at 5:41 PM, Alan Kim Zimmerman alan.z...@gmail.com wrote: I already tried that, the syntax does not seem to allow it. I suspect some higher form of sorcery will be required, as alluded to here http://stackoverflow.com/questions/14133121/can-i-constrain-a-type-family Alan On Mon, Jul 28, 2014 at 4:55 PM, p.k.f.holzensp...@utwente.nl wrote: Dear Alan, I would think you would want to constrain the result, i.e. type family (Data (PostTcType a)) = PostTcType a where … The Data-instance of ‘a’ doesn’t give you much if you have a ‘PostTcType a’. Your point about SYB-recognition of WrongPhase is, of course, a good one ;) Regards, Philip *From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com] *Sent:* maandag 28 juli 2014 14:10 *To:* Holzenspies, P.K.F. (EWI) *Cc:* Simon Peyton Jones; Edward Kmett; ghc-devs@haskell.org *Subject:* Re: Broken Data.Data instances Philip I think the main reason for the WrongPhase thing is to have something that explicitly has a Data and Typeable instance, to allow generic (SYB) traversal. If we can get by without this so much the better. On a related note, is there any way to constrain the 'a' in type family PostTcType a where PostTcType Id= TcType PostTcType other = WrongPhaseTyp to have an instance of Data? I am experimenting with traversals over my earlier paste, and got stuck here (which is the reason the Show instances were commentet out in the original). Alan On Mon, Jul 28, 2014 at 12:30 PM, p.k.f.holzensp...@utwente.nl wrote: Sorry about that… I’m having it out with my terminal server and the server seems to be winning. Here’s another go: I always read the () as “there’s nothing meaningful to stick in here, but I have to stick in something” so I don’t necessarily want the WrongPhase-thing. There is very old commentary stating it would be lovely if someone could expose the PostTcType as a parameter of the AST-types, but that there are so many types and constructors, that it’s a boring chore to do. Actually, I was hoping haRe would come up to speed to be able to do this. That being said, I think Simon’s idea to turn PostTcType into a type-family is a better way altogether; it also documents intent, i.e. () may not say so much, but PostTcType RdrName says quite a lot. Simon commented that a lot of the internal structures aren’t trees, but cyclic graphs, e.g. the TyCon for Maybe references the DataCons for Just and Nothing, which again refer to the TyCon for Maybe. I was wondering whether it would be possible to make stateful lenses for this. Of course, for specific cases, we could do this, but I wonder if it is also possible to have lenses remember the things they visited and not visit them twice. Any ideas on this, Edward? Regards, Philip *From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com] *Sent:* maandag 28 juli 2014 11:14 *To:* Simon Peyton Jones *Cc:* Edward Kmett; Holzenspies, P.K.F. (EWI); ghc-devs *Subject:* Re: Broken Data.Data instances I have made a conceptual example of this here http://lpaste.net/108262 Alan On Mon, Jul 28, 2014 at 9:50 AM, Alan Kim Zimmerman alan.z...@gmail.com wrote: What about creating a specific type with a single constructor for the not relevant to this phase type to be used instead of () above? That would also clearly document what was going on. Alan On Mon, Jul 28, 2014 at 9:14 AM, Simon Peyton Jones simo...@microsoft.com wrote: I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used to be built this way before I convinced the authors to switch to safer versions of Data. Using virtual smart constructors like we do now in containers and Text where needed can be used to preserve internal invariants, etc. If the “hand grenades” are the PostTcTypes, etc, then I can explain why they are there. There simply is no sensible type you can put before the type checker runs. For example one of the constructors in HsExpr is | HsMultiIf PostTcType [LGRHS id (LHsExpr id)] After type checking we know what type the thing has, but before we have no clue. We could get around this by saying type PostTcType = Maybe TcType but that would mean that every post-typechecking consumer would need a redundant pattern-match on a Just that would always succeed. It’s nothing deeper than that. Adding Maybes everywhere would be possible, just clunky. However we now have type functions, and HsExpr is parameterised by an ‘id’ parameter, which changes from RdrName (after parsing) to Name (after renaming) to Id (after typechecking). So we could do this: | HsMultiIf (PostTcType id) [LGRHS id (LHsExpr id)] and define PostTcType as a closed type family thus type family PostTcType a where
Re: Dashboard
Hi Joachim, I think automatic regression notification at least to the author is a good idea. Probably I can do it in a nearest time. Unfortunately, right now I fail to get your code up. Also I believe it is a good style to check commits for regressions before pushing them. But maybe GHC community is less performance oriented. 25.07.2014, 01:41, Joachim Breitner m...@joachim-breitner.de: Hi Alexander, Am Donnerstag, den 24.07.2014, 19:22 +0400 schrieb Alexander Pakhomov: I've been informed you created http://ghcspeed-nomeata.rhcloud.com. I believe it is necessary for any serious perfomance work. Do you need some help? What have you done and what problems are unsolved? thanks for your interest. One way to help is to monitor the page for regressions, and notify whoever caused it. I’m doing that from time to time, relying on the Latest Results summary. Then I don’t find the codespeed software to be perfect. The thread at https://groups.google.com/forum/#!topic/codespeed/yY5-kPrcG94 discusses some of the things I don’t like. So if you feel like hacking Python, just hack away on it and I’ll happily accept pull requests at https://github.com/nomeata/codespeed (branch ghc), or directly upstream. Eventually, the whole setup should be moved to some dedicated and official hardware, but I’m not in a hurry with this. It’s been running for just a week or two, and I’d like to observe how its behaving. Greetings, Joachim PS: I prefer to discuss these things on the appropriate mailing list and in public, if only for the archive. If you agree, simply reply to the ghc-dev list (quoting in full) and I’ll read your reply there. -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
