Code redundancy in PrelNames?

Jan Stolarek jan.stolarek at
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. 


More information about the ghc-devs mailing list