I think there is at least something to be said for module names that are unique, mainly for the human interface.
For example, I often say (in Notes or Gitlab comments) "In TcType.foo we see ...". Now I could say "In GHC.Hs.Typecheck.Type we see ..." but it's less convenient. I could take the shortest unique prefix "In Typecheck.Type we see ...", but then I need to figure out what name clashes there are and add a disambiguating prefix.
This is not a do-or-die issue. But my instinct is to avoid name clashes where we can.
Simon
| -----Original Message-----
| From: ghc-devs On Behalf Of Ömer Sinan
| Agacan
| Sent: 25 October 2019 07:44
| To: Andreas Klebinger
| Cc: GHC developers
| Subject: Re: How to navigate around the source tree?
|
| > While there are workarounds, both for my case as for Matts. It's worth
| asking
| > if requiring these workarounds is better than just accepting redundant
| > prefixes on module names.
|
| "Workarounds" are for problems, but I don't understand why duplicate file
| names
| are a problem. Can you elaborate? Perhaps this is problem with your
| IDE/editor
| setup? Many of us (as can be seen in responses) use tools/editors/IDEs
| that can
| handle this just fine.
|
| I worked on projects with duplicate file names in the past too; having
| tools
| that can deal with this helps, and I don't think this is too hard to
| achieve.
| You can't ask devs of every project you join to rename their files because
| your
| editor can't handle them.
|
| (I don't know VS Code enough to help ..)
|
| Ömer
|
| Andreas Klebinger , 24 Eki 2019 Per, 14:48
| tarihinde şunu yazdı:
| >
| > Hello devs,
| >
| > I also often jump to files. In my case usually using VS Code using Ctr+P
| as well which searches for files by name.
| > While I can check which folder a file is in in the case of duplicates it
| is a overhead which this refactor forces onto me.
| >
| > While there are workarounds, both for my case as for Matts. It's worth
| asking if requiring these workarounds is better
| > than just accepting redundant prefixes on module names.
| >
| > Personally I would prefer unique file names even at the cost of
| redundancy.
| > I rarely add import statements/full module names, but I *very* often
| jump to files.
| >
| > Cheers
| > Andreas
| >
| > Bryan Richter schrieb am 23.10.2019 um 18:00:
| >
| > Duplicate record fields is going to make this a bigger problem. Vim does
| support duplicate tags (:tselect and :tjump and related bindings), but
| hopefully haskell-ide-engine will one day provide us with semantic tags
| and solve this problem once and for all!
| >
| > On Wed, 23 Oct 2019, 17.49 Matthew Pickering,
| wrote:
| >>
| >> Thanks Omer, Sylvain and Sebastian
| >>
| >> .
| >>
| >> I just configured my editor to use fzf and now I can use the `:GFiles`
| >> command to perform fuzzy search on files which is probably better than
| >> tags. If anyone else is using NixOS, all I had to do was add the
| >> `fzf-vim` plugin to the vim configuration.
| >>
| >> Cheers,
| >>
| >> Matt
| >>
| >> On Wed, Oct 23, 2019 at 2:54 PM Ömer Sinan Ağacan
| wrote:
| >> >
| >> > I use a file finder (fzf) for jumping to files. Because module names
| follow file
| >> > paths to jump to e.g. StgToCmmUtils.Utils I usually type `stgcmmutils` and
| >> > fzf finds the correct file `compiler/GHC/StgToCmm/Utils.hs`.
| >> >
| >> > When generating tags I omit module names for this reason, it's easy
| with a good
| >> > file finder to jump to modules already, no need to generate tags for
| the
| >> > modules.
| >> >
| >> > fast-tags commands I use:
| >> >
| >> > - When working on the compiler:
| >> >
| >> > $ fast-tags --no-module-tags driver ghc compiler
| >> >
| >> > - When working on the RTS:
| >> >
| >> > $ fast-tags --no-module-tags driver ghc compiler
| >> > $ ctags --append -R rts/**/*.c rts/**/*.h includes/**/*.h
| >> >
| >> > - When working on the libraries:
| >> >
| >> > $ fast-tags --no-module-tags driver ghc compiler libraries
| >> >
| >> > Ömer
| >> >
| >> > Sebastian Graf , 23 Eki 2019 Çar, 16:49
| tarihinde
| >> > şunu yazdı:
| >> > >
| >> > > FWIW, I'm using VSCode's fuzzy file search with Ctrl+P (and vim's
| equivalent) rather successfully. Just tried it for Hs/Utils.hs by typing
| 'hsutils.hs'. It didn't turn up as the first result in VSCode, but it in
| vim.
| >> > >
| >> > > Am Mi., 23. Okt. 2019 um 14:27 Uhr schrieb Matthew Pickering
| :
| >> > >>
| >> > >> I use `fast-tags` which doesn't look at the hierarchy at all and
| I'm
| >> > >> not sure what the improvement would be as the names of the modules
| >> > >> would still clash.
| >> > >>
| >> > >> If there is some other recommended way to jump to a module then
| that
| >> > >> would also work for me.
| >> > >>
| >> > >> Matt
| >> > >>
| >> > >>
| >> > >> On Wed, Oct 23, 2019 at 12:08 PM Sylvain Henry
| wrote:
| >> > >> >
| >> > >> > Hi,
| >> > >> >
| >> > >> > How do you generate your tags file? It seems to be a shortcoming
| of the
| >> > >> > generator to not take into account the location of the
| definition file.
| >> > >> >
| >> > >> > > Perhaps `HsUtils` and `StgUtils` would be appropriate to
| >> > >> > disambiguate`Hs/Utils` and `StgToCmm/Utils`.
| >> > >> >
| >> > >> > We are promoting the module prefixes (`Hs`, `Stg`, `Tc`, etc.)
| into
| >> > >> > proper module layers (e.g. `HsUtils` becomes `GHC.Hs.Utils`) so
| it would
| >> > >> > be redundant to add the prefixes back. :/
| >> > >> >
| >> > >> > Cheers,
| >> > >> > Sylvain
| >> > >> >
| >> > >> > On 23/10/2019 12:52, Matthew Pickering wrote:
| >> > >> > > Hi,
| >> > >> > >
| >> > >> > > The module rework has broken my workflow.
| >> > >> > >
| >> > >> > > Now my tags file is useless for jumping for modules as there
| are
| >> > >> > > multiple "Utils" and "Types" modules. Invariable I am jumping
| to the
| >> > >> > > wrong one. What do other people do to avoid this?
| >> > >> > >
| >> > >> > > Can we either revert these changes or give these modules
| unique names
| >> > >> > > to facilitate that only reliable way of navigating the code
| base.
| >> > >> > > Perhaps `HsUtils` and `StgUtils` would be appropriate to
| disambiguate
| >> > >> > > `Hs/Utils` and `StgToCmm/Utils`.
| >> > >> > >
| >> > >> > > Cheers,
| >> > >> > >
| >> > >> > > Matt
| >> > >> > > _______________________________________________
| >> > >> > > ghc-devs mailing list
| >> > >> > > ghc-devs@haskell.org
| >> > >> > >
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7C3ffb77db43b74c34a0af08d7
| 5916d1e4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637075826856171272&a
| mp;sdata=H%2BCCWwdR%2Fv1rhnYi%2BBuFPvB5pzlFpHkqdsG6S0tVOfE%3D&reserved
| =0
| >> > >> > _______________________________________________
| >> > >> > ghc-devs mailing list
| >> > >> > ghc-devs@haskell.org
| >> > >> >
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7C3ffb77db43b74c34a0af08d7
| 5916d1e4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637075826856171272&a
| mp;sdata=H%2BCCWwdR%2Fv1rhnYi%2BBuFPvB5pzlFpHkqdsG6S0tVOfE%3D&reserved
| =0
| >> > >> _______________________________________________
| >> > >> ghc-devs mailing list
| >> > >> ghc-devs@haskell.org
| >> > >>
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7C3ffb77db43b74c34a0af08d7
| 5916d1e4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637075826856171272&a
| mp;sdata=H%2BCCWwdR%2Fv1rhnYi%2BBuFPvB5pzlFpHkqdsG6S0tVOfE%3D&reserved
| =0
| >> > >
| >> > > _______________________________________________
| >> > > ghc-devs mailing list
| >> > > ghc-devs@haskell.org
| >> > >
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7C3ffb77db43b74c34a0af08d7
| 5916d1e4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637075826856181264&a
| mp;sdata=qU2fbJithYT0tvxy299nYcjYPk265OxnKzJLRtb%2FpVI%3D&reserved=0
| >> _______________________________________________
| >> ghc-devs mailing list
| >> ghc-devs@haskell.org
| >>
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7C3ffb77db43b74c34a0af08d7
| 5916d1e4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637075826856181264&a
| mp;sdata=qU2fbJithYT0tvxy299nYcjYPk265OxnKzJLRtb%2FpVI%3D&reserved=0
| >
| >
| >
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs@haskell.org
| >
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7C3ffb77db43b74c34a0af08d7
| 5916d1e4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637075826856181264&a
| mp;sdata=qU2fbJithYT0tvxy299nYcjYPk265OxnKzJLRtb%2FpVI%3D&reserved=0
| >
| >
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs@haskell.org
| >
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7C3ffb77db43b74c34a0af08d7
| 5916d1e4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637075826856181264&a
| mp;sdata=qU2fbJithYT0tvxy299nYcjYPk265OxnKzJLRtb%2FpVI%3D&reserved=0
| _______________________________________________
| ghc-devs mailing list
| ghc-devs@haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7C3ffb77db43b74c34a0af08d7
| 5916d1e4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637075826856181264&a
| mp;sdata=qU2fbJithYT0tvxy299nYcjYPk265OxnKzJLRtb%2FpVI%3D&reserved=0
