Warn on module name not matching file structure

[GoNZooo]

@jmackie brought up on Slack today that it might be nice to enforce that a module is named in such a way that it can be easily found in the file structure of the project.

The desired structure is usually that the module Data.Foo is defined in the file src/Data/Foo.purs and departing from that may be unwise.

With that in mind, it might be nice to have at least a compile-time warning, potentially something you could disable if you've made a conscious choice to avoid this structure. I suppose any warning could be ignored via purescript-psa, but I don't know what kind of precedent there already is for error suppression otherwise.

[adnelson]

Just throwing this idea out there, but if the module name is expected to match the file name, why not just eschew the module name entirely and allow it to be derived from the path to the file? It's always annoyed me in Haskell that I am forced to rename modules if I move the file, because it seems like purely redundant information. Furthermore, deriving a module name from a file path is a pattern in many other languages, including python, javascript, ocaml and rust.

[natefaubion]

PS is a batch compiler, so I'm not sure how we would eschew module names completely. Likewise, we would have to have a fairly conservative rule if this were a warning, since modules/files can come from anywhere.

[adnelson]

Sorry I wasn't clear. I didn't mean to not have any concept of module names. The name would still exist; it's just that the compiler could use the relative path to the module to create it rather than it needing to be present in the source code.

[natefaubion]

Something like that would probably require #3493.

[adnelson]

Thanks for the link; I read through a few discussions on the matter. I'm not certain it's required -- or at least, I don't know if it's any more required than it would be to implement the behavior requested in this issue. After all, in order to warn that the module has the wrong name, the compiler would have to have some way to know what the "right name" should be, in which case it would have enough information to generate it automatically.

On a related note, this definitely made me curious about taking a look at adding package-awareness to the compiler... :)

[natefaubion]

After all, in order to warn that the module has the wrong name, the compiler would have to have some way to know what the "right name" should be, in which case it would have enough information to generate it automatically.

That's why I said the check would have to be conservative. It would probably have to take the provided module name, and verify that it's a sub-path of it's location.

[JordanMartinez]

I thought I'd mention this (but not as something that means we shouldn't do this). I'm currently exploiting the fact that the module name does not have to match the file name/structure in my learning repo. For example, I use numerical ordering to sort how things are displayed and direct readers on where to start first (e.g. 01-File.purs, 02-File2.purs, etc.). So, if this is implemented, I'll just need to rename most of the files/folders in that learning repo.

[GoNZooo]

I use numerical ordering to sort how things are displayed and direct readers on where to start first (e.g. 01-File.purs, 02-File2.purs, etc.). So, if this is implemented, I'll just need to rename most of the files/folders in that learning repo.

I do this as well in a learning repo, which is why I wanted a way to turn the warning off. Prefixing by number in order to have people know what to do next is better than forcing them to look at some index/table of contents in the README.

The reason I think the change is good from the beginning is because it's easier to nudge people in the right direction instead of them figuring it out from seeing it in other repos. It'd be nice if there was a way for them to fall into the pit of success, but I don't think there's a feasible solution to that.

[JordanMartinez]

Good point.