Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Qualified imports by default #77

Open
NickSeagull opened this issue Oct 16, 2023 · 0 comments
Open

Qualified imports by default #77

NickSeagull opened this issue Oct 16, 2023 · 0 comments
Labels

Comments

@NickSeagull
Copy link
Contributor

@DNEAVES proposed in Discord the following:

In regards to learning Haskell, one of the major roadblocks for myself was finding out where a function, type constructor, or symbol came from. In some cases, this even includes Prelude functions, if one doesn't know what the Prelude in Haskell even is.

I'll address the topic of symbols separately. For the rest, not knowing what modules to use creates a degree of difficulty to learning a language. For the following I'll take reference from Elm:

In Elm, every import is qualified by default, without a need for a "qualified" keyword (only without the namespace if specifically named in the import as exposed). This creates a sense of knowing where a function or type is from when reading other's code. Because we're not always writing code, sometimes we're reading/reviewing it, too. This is also part of how people learn a language, and if code is difficult to read, its difficult to learn.

(Now, in regards to Elm, there is the package-name/import-name difference, just like Haskell. But this will be proposed separately)

This may result in a few more characters a developer has to type, yes. But its less time the next developer has to take to comprehend the first developer's code.

I agree on the last sentence 100%. The language should be always optimized to be read first, and written second.

Feature Description

In addition to qualification, if the module defines a type that is of the same name as the module itself, the type (and only the type, not the constructors) will be imported unqualified:

-- NeoHaskell syntax - regular import
import Text

-- Haskell syntax -  will be translated to
import qualified Text
import Text (Text)

Note on unqualified imports

Unqualified imports should not be supported directly right now. Let's first see how the language evolves through the usage of only qualified imports, and then if we see it necessary, we will add it. Implementing a feature is a one-way door (you cannot un-implement something).

Still, unqualified imports are required for the core library. But this one will be added by the compiler to the source code as the second line of every file, so it can be done after desugaring the imports.

Reference material

There are two plugins that could help us implement what we want, using them as reference:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant