-
Simon Peyton Jones authored
For some time we have had two free-variable mechanims for types: * The "FV" mechanism, embodied in GHC.Utils.FV, which worked OK, but was fragile where eta-expansion was concerned. * The TyCoFolder mechanism, using a one-shot EndoOS accumulator I finally got tired of this and refactored the whole thing, thereby addressing #27080. Now we have * `GHC.Types.Var.FV`, which has a composable free-variable result type, very much in the spirit of the old `FV`, but much more robust. (It uses the "one shot trick".) * GHC.Core.TyCo.FVs now has just one technology for free variables. All this led to a lot of renaming. There are couple of error-message changes. The change in T18451 makes an already-poor error message even more mysterious. But it really needs a separate look. We also now traverse the AST in a different order leading to a different but still deterministic order for FVs and test output has been adjusted accordingly.
Simon Peyton Jones authoredFor some time we have had two free-variable mechanims for types: * The "FV" mechanism, embodied in GHC.Utils.FV, which worked OK, but was fragile where eta-expansion was concerned. * The TyCoFolder mechanism, using a one-shot EndoOS accumulator I finally got tired of this and refactored the whole thing, thereby addressing #27080. Now we have * `GHC.Types.Var.FV`, which has a composable free-variable result type, very much in the spirit of the old `FV`, but much more robust. (It uses the "one shot trick".) * GHC.Core.TyCo.FVs now has just one technology for free variables. All this led to a lot of renaming. There are couple of error-message changes. The change in T18451 makes an already-poor error message even more mysterious. But it really needs a separate look. We also now traverse the AST in a different order leading to a different but still deterministic order for FVs and test output has been adjusted accordingly.
Loading