You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 importimportText-- Haskell syntax - will be translated toimportqualifiedTextimportText (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:
@DNEAVES proposed in Discord the following:
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:
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:
The text was updated successfully, but these errors were encountered: