-
Notifications
You must be signed in to change notification settings - Fork 571
Description
Related to #2415. /cc @ivan-kleshnin
At the moment, module names are globally unique. This presents some problems:
- If you depend on two separate packages which both define a module with the same name, you are stuck. The only recourse is to nicely ask the authors of one or the other to change a module name, or fork one and change the module name yourself.
- If you're reading someone else's code and you see code from packages you're not familiar with, it's not clear which packages certain modules come from.
- We have this slightly weird hierarchy, inherited from Haskell, that sometimes makes it difficult to guess where a module goes and is often a bit verbose. ("Do I want
Data.LazyorControl.Lazy?" "Why is itData.FunctorbutControl.Monad?" "I am a little bored of typing outControl.Monad.Eff.Console.")
Before continuing I would like to draw attention to other initiatives that do partially address both of these:
- Package sets address the uniqueness problem by requiring that all packages in a set build together, thereby ensuring that within a package set, module names are unique. However I don't think that we should expect all library code will end up in a package set; putting libraries into a package set is a commitment that not everyone will want or be able to make.
- Editor integration helps track down where names or modules come from. However editor integration isn't available everywhere - for example, when reviewing code on web apps like GitHub, when reading blog posts on the web which include PureScript code, or when it just isn't installed on the machine you're using (for whatever reason - maybe it isn't your main dev machine).
- It should be possible to input module names in the search box in Pursuit, and the search results should link to all the packages which define modules of that name. But again, sometimes I'm writing code and I don't have internet access, and if there are lots of imports in a module which I don't recognise, this is a lot of hassle.
The only way I can see to fully address these issues is to change the language so that modules must only be unique within a package, and change import declarations so that they explicitly say which package a module is coming from. I agree that we ideally want to keep the compiler as unaware of our approach to packaging as possible - this enables us to work on experiments like psc-package without compiler changes, which is great. So I propose that, as far as the compiler is concerned, a "package" is just a name (which must be unique) and a collection of modules. Import declarations could look like this:
import "prelude" Prelude
import "lists" List as List
import "foldable-traversable" Traversable (traverse)
import "console" Console (log, logShow)
import "transformers" Writer.Trans as WriterT
import "transformers" Reader.Class (asks)Note that we can now ditch the Data., Control.Monad., etc. prefixes. The impact of this would be pretty huge, admittedly. But I am quite confident that it would pay off fairly soon.