From 7f5ccbc6872a51cd60e9bd0fc549938f83d6c1f4 Mon Sep 17 00:00:00 2001 From: "simonpj@microsoft.com" Date: Thu, 15 Oct 2009 11:55:46 +0000 Subject: [PATCH] Correct comment --- compiler/coreSyn/CorePrep.lhs | 1 - compiler/iface/MkIface.lhs | 2 +- compiler/main/TidyPgm.lhs | 12 +++++++++++- 3 files changed, 12 insertions(+), 3 deletions(-) diff --git a/compiler/coreSyn/CorePrep.lhs b/compiler/coreSyn/CorePrep.lhs index 89ec98f..2a5987c 100644 --- a/compiler/coreSyn/CorePrep.lhs +++ b/compiler/coreSyn/CorePrep.lhs @@ -86,7 +86,6 @@ The goal of this pass is to prepare for code generation. 8. Inject bindings for the "implicit" Ids: * Constructor wrappers * Constructor workers - * Record selectors We want curried definitions for all of these in case they aren't inlined by some caller. diff --git a/compiler/iface/MkIface.lhs b/compiler/iface/MkIface.lhs index 4de3a6f..15fa778 100644 --- a/compiler/iface/MkIface.lhs +++ b/compiler/iface/MkIface.lhs @@ -497,7 +497,7 @@ addFingerprints hsc_env mb_old_fingerprint iface0 new_decls let sorted_deps = sortDependencies (mi_deps iface0) -- the export hash of a module depends on the orphan hashes of the - -- orphan modules below us in the dependeny tree. This is the way + -- orphan modules below us in the dependency tree. This is the way -- that changes in orphans get propagated all the way up the -- dependency tree. We only care about orphan modules in the current -- package, because changes to orphans outside this package will be diff --git a/compiler/main/TidyPgm.lhs b/compiler/main/TidyPgm.lhs index 6aafe24..e87bac6 100644 --- a/compiler/main/TidyPgm.lhs +++ b/compiler/main/TidyPgm.lhs @@ -496,6 +496,11 @@ why CoreUnfold.mkImplicitUnfolding uses simleExprOpt to do a bit of optimisation first. (Only matters when the selector is used curried; eg map x ys.) See Trac #2070. +[Oct 09: in fact, record selectors are no longer implicit Ids at all, +because we really do want to optimise them properly. They are treated +much like any other Id. But doing "light" optimisation on an implicit +Id still makes sense.] + At one time I tried injecting the implicit bindings *early*, at the beginning of SimplCore. But that gave rise to real difficulty, becuase GlobalIds are supposed to have *fixed* IdInfo, but the @@ -506,18 +511,23 @@ importing modules were expecting it to have arity 1 (Trac #2844). It's much safer just to inject them right at the end, after tidying. Oh: two other reasons for injecting them late: + - If implicit Ids are already in the bindings when we start TidyPgm, we'd have to be careful not to treat them as external Ids (in the sense of findExternalIds); else the Ids mentioned in *their* RHSs will be treated as external and you get an interface file saying a18 = but nothing refererring to a18 (because the implicit Id is the - one that does). + one that does, and implicit Ids don't appear in interface files). - More seriously, the tidied type-envt will include the implicit Id replete with a18 in its unfolding; but we won't take account of a18 when computing a fingerprint for the class; result chaos. +There is one sort of implicit binding that is injected still later, +namely those for data constructor workers. Reason (I think): it's +really just a code generation trick.... binding itself makes no sense. +See CorePrep Note [Data constructor workers]. \begin{code} getImplicitBinds :: TypeEnv -> [CoreBind] -- 1.7.10.4