Code redundancy in PrelNames?
Jan Stolarek
jan.stolarek at p.lodz.pl
Wed Jul 2 07:57:57 UTC 2014
I'm looking at PrelNames.lhs and I believe there is some redundancy that can also lead to
confusion. Consider these definitions:
bindMName = methName gHC_BASE (fsLit ">>=") bindMClassOpKey
arrAName = varQual aRROW (fsLit "arr") arrAIdKey
Former is defined as "methName", while the latter is "varQual". These are defined like this:
varQual :: Module -> FastString -> Unique -> Name
varQual = mk_known_key_name varName
mk_known_key_name :: NameSpace -> Module -> FastString -> Unique -> Name
mk_known_key_name space modu str unique
= mkExternalName unique modu (mkOccNameFS space str) noSrcSpan
methName :: Module -> FastString -> Unique -> Name
methName modu occ unique
= mkExternalName unique modu (mkVarOccFS occ) noSrcSpan
Expanding the call to mk_known_key_name in varQual the RHS of varQual becomes :
mkExternalName unique modu (mkOccNameFS varName str) noSrcSpan
Now, the call to "mkVarOccFS occ" in methName resolves to "mkOccNameFS varName occ", making the
call to varQual identical to methName.
Is this redundancy a conscious choice or just an accident? If it's conscious then what is the
purpose? I spent several minutes trying to understand why bindMName and arrAName are defined
differently. Names suggest that bindMName is a method, while arrAName is a qualified variable. I
find this confusing and I think it would be better to drop varQual in favour of methName.
Thoughts?
Janek
More information about the ghc-devs
mailing list