Code redundancy in PrelNames?
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
| Is this redundancy a conscious choice or just an accident? If it's It's an accident. Good catch. I suggest eliminating methName and using varQual instead. The reverse doesn't work; varQual is used a lot! thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Jan | Stolarek | Sent: 02 July 2014 08:58 | To: ghc-devs@haskell.org | Subject: Code redundancy in PrelNames? | | 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 | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs
participants (2)
-
Jan Stolarek -
Simon Peyton Jones