Shorter import syntax

changed weight to 5

added Tfeature request Trac import labels

I had forgotten about the existing import Data.Map as M syntax. So, to clarify, the proposed syntax will require the parenthetical part. This offers a new way of writing a qualified import: import Foo() as F.

Note that currently the next is allowed:

import Data.Map as M (Map)

Different semantics based on order of parens and as is too ambiguous and hard to remember IMO.

Also, the existing convention to import data type unqualified and the rest qualified is some kind of a hack working around lack of nested namespaces. In the ideal world Data.Map should export functions qualified. Like the next:

module Data.Map
(Map, namespace Map)
where

data Map = ...

namespace Map where
  length :: Map -> Int
  length ...

I'm in favor of abbreviating the syntax in this common scenario, but I don't like your choice of syntax, I'm afraid. It would give

import Data.Map (Map) as M    -- (1)

a very different meaning from

import Data.Map as M (Map)    -- (2)

(1) imports all of Data.Map, qualified with the alias M, and imports the name Map unqualified. (2) imports only the name Map (unqualified) while also aliasing Data.Map. Having these two coexist seems like we're asking users to be confused.

What about

import Data.Map (Map)
  qualified as M *

?

The general schema, which replaces the current syntax. This schema does not permit some current syntax, but it would be easy to extend it to be backward-compatible. I've chosen not to for this presentation to avoid clutter.

import_statement  ::= 'import' module_name maybe_name_list import_specifiers
module_name       ::= ...
maybe_name_list   ::= name_list | <empty>
name_list         ::= '(' names ')' | '*'
import_specifiers ::= <empty> | import_specifier import_specifiers
import_specifier  ::= 'hiding' name_list | qualified_spec name_list
qualified_spec    ::= 'qualified' | 'qualified' 'as' name

The top-level maybe_name_list would list all unqualified imports. If it is omitted, and there are no qualified_specs, then all names would be imported unqualified. If it is omitted and there are one or more qualified_specs, then no names would be imported unqualified.

Each import_specifier either adds qualified names (perhaps under a module synonym) or removes names. Removing names with hiding removes those names from the qualified_spec (or top-level maybe_name_list) immediately preceding the hiding.

The special name_list * (note that it is not in parentheses, to avoid ambiguity) means "all names".

This schema allows one import statement to import a mix of qualified and unqualified names, and even allows using different module synonyms for different sets of qualified names. The legacy import syntax could desugar to this form, which seems strictly more expressive. For example:

import qualified Foo       -->  import Foo qualified *
import qualified Bar as B  -->  import Bar qualified as B *
import Baz hiding (wurble) -->  import Baz hiding (wurble)

Thoughts?

Why not use (..) instead of *? It seems more consistent with Haskell's current syntax.

Replying to [ticket:10478#comment:100377 Rufflewind]:

Why not use (..) instead of *? It seems more consistent with Haskell's current syntax.

Sold. I like this much more than *. It was also suggested that (..) could be omitted if it were going to be the last item on the line. I'm happy with that suggestion, too.

Why not?

import qualified Data.Map (Map) as M

While it is qualified import it should have keyword "qualified" to specify that explicitly.

Replying to [ticket:10478#comment:100450 s9gf4ult]:

Why not?

import qualified Data.Map (Map) as M

While it is qualified import it should have keyword "qualified" to specify that explicitly.

The qualified applies to M but not to (Map).

The qualified applies to M but not to (Map).

Yes, but this syntax still looks more logical than without "qaulified". It is not obvious to see something like

import Data.Map (Map) as M

And have module Data.Map imported qualified as M.

I don't think a desire to keep the qualified word is more logical or obvious than any other option. I can't think of another programming language that uses the qualified keyword. Agda uses import M as N to create a qualified alias. Python imports qualified by default. But this is Haskell, so we should consider how Haskell is used. If you grep over the source of all packages in the Stackage package set, you will find that import statements that use the as keyword are qualified 10x more than unqualified. If you focus on the specific syntax, import Foo as F(bar), it is used in less than 0.3% of all import statements. So we are loading by far the more common usage with extra syntax.

I suggest a way of reading import statements as "import ModuleName (unqualifiedImports)" If you want to use qualified names, all of that information is given by appending a suffix to the import statement beginning with the as keyword.

This is certainly new syntax, but I have yet to see any quantifiable argument that it is less logical or undesired (see the support for the proposal linked from the haskell-cafe thread). Also note that the proposal will not break anything: if you find qualified easier to read, then you can continue to use it. If nobody uses the new syntax because it is hard to understand, then nobody will suffer.

Other discussions of this proposal:

And other proposals:

https://github.com/chreekat/blatherings/blob/master/haskell-imports.md

Trac metadata

Trac field	Value
Differential revisions	- → D1238

Here is an overview for two of the proposals listed on this ticket. Please inform me of any mistakes there might be, and I will edit this comment.

I'm using the variant of goldfire's proposal with (..) instead of *, and where (..) at the end of the line can be omitted.

@goldfire: I understand your proposal would (also) be fully backward compatible. Please tell me on which rows you would recommend to use the old syntax. And maybe there's a useful trick only your proposal supports?

Suppose the module A exports x and y.

Without a module alias:

\#	Haskell 2010	Proposal acowley	Proposal goldfire	Brings into scope
1	import A	\\import A\\	\\import A\\	x, y, A.x, A.y
2	import A (x)	\\import A (x)\\	\\import A (x)\\	x, A.x
3	import qualified A	\\import A () as A\\	\\import A qualified\\	A.x, A.y
4	import qualified A (x)	\\import A () as A (x)\\	\\import A qualified (x)\\	A.x

With a module alias:

||= # =||= Haskell 2010 =||= Proposal acowley =||= Proposal goldfire =||= Brings into scope =||

||= 5 =|| import A as B || **import A as B** || **import A (..) qualified as B** || x, y, B.x, B.y ||

||= 6 =|| import A as B (x) || **import A as B (x)** || **import A (x) qualified as B (x)** || x, B.x ||

||= 7 =|| import qualified A as B || **import A () as B** || **import A qualified as B** || B.x, B.y ||

8	import qualified A as B (x)	\\import A () as B (x)\\	\\import A qualified as B (x)\\	B.x

The real deal:

\#	Haskell 2010	Proposal acowley	Proposal goldfire	Brings into scope
9	import A (x);	\\import A (x) as B\\	\\import A (x) qualified as B\\	x, B.x, B.y
	import qualified A as B
10	//(impossible)//	\\import A (x) as X ()\\	\\import A (x) qualified ()\\	x

Potentially confusing things about these proposals, assuming full backward compatibility:

proposal	H2010 syntax	new syntax	Why confusing?
acowley	\\import A as B (x)\\	\\import A (x) as B\\	look similar, do different things
goldfire	\\import qualified A as B (x)\\	\\import A (x) qualified as B\\	look similar, do different things
goldfire	\\import qualified A\\	\\import A qualified\\	look different, do the same thing

Perhaps my proposal was not clearly stated. I have modified the examples below to support my intent. If you see an error in the proposal, please do let me know! My changes affect the first block and the very last line.

Suppose the module A exports x and y.

Without a module alias:

\# Haskell 2010 Proposal acowley Proposal goldfire Brings into scope

1 import A \*\*import A\*\* \*\*import A\*\* x, y, A.x, A.y

2 import A (x) \*\*import A (x)\*\* \*\*import A (x)\*\* x, A.x

3 import qualified A \*\*import A () as A\*\* \*\*import A qualified\*\* A.x, A.y

4 import qualified A (x) \*\*import A () as A (x)\*\* \*\*import A qualified (x)\*\* A.x

With a module alias:

||= # =||= Haskell 2010 =||= Proposal acowley =||= Proposal goldfire =||= Brings into scope =||

||= 5 =|| import A as B || **import A as B** || **import A (..) qualified as B** || x, y, B.x, B.y ||

||= 6 =|| import A as B (x) || **import A as B (x)** || **import A (x) qualified as B (x)** || x, B.x ||

||= 7 =|| import qualified A as B || **import A () as B** || **import A qualified as B** || B.x, B.y ||

8 import qualified A as B (x) \*\*import A () as B (x)\*\* \*\*import A qualified as B (x)\*\* B.x

The real deal:

\# Haskell 2010 Proposal acowley Proposal goldfire Brings into scope

9 import A (x); \*\*import A (x) as B\*\* \*\*import A (x) qualified as B\*\* x, B.x, B.y

import qualified A as B

10 //(impossible)// \*\*import A (x) as X ()\*\* \*\*import A (x) qualified ()\*\* x

Potentially confusing things about these proposals, assuming full backward compatibility:

proposal H2010 syntax new syntax Why confusing?

acowley \*\*import A as B (x)\*\* \*\*import A (x) as B\*\* look similar, do different things

goldfire \*\*import qualified A as B (x)\*\* \*\*import A (x) qualified as B\*\* look similar, do different things

goldfire \*\*import qualified A\*\* \*\*import A qualified\*\* look different, do the same thing

goldfire \*\*import qualified A (..)\*\* \*\*import A (..) qualified\*\* look similar, do different things

What is the difference between import qualified A and import A qualified (row 3)?

Replying to [ticket:10478#comment:106940 thomie]:

What is the difference between import qualified A and import A qualified (row 3)?

You're right. Those are the same. I've edited it all to clarify.

import qualified A (..) brings A.x and A.y into scope.

import A (..) qualified brings x, y, A.x, and A.y into scope.

Replying to [ticket:10478#comment:106891 thomie]:

Potentially confusing things about these proposals, assuming full backward compatibility:

proposal H2010 syntax new syntax Why confusing?

acowley \*\*import A as B (x)\*\* \*\*import A (x) as B\*\* look similar, do different things

Just to chime in to confirm that this is the most ripe for confusion part of the proposal. No semantics of working code change with the extension enabled, but this point of confusion is introduced. For context, the syntax import A as B (x) is used in 0.3% of all import statements over all the code in the Stackage package set.

acowley: you could avoid the confusion by saying import A (x) as B (..). But I'm not sure that's worth it.

Summary of the previous mailinglist discussion and reddit thread:

A lot (15?) of people on the mailinglist were in favour of acowley's proposal, or at least for some form of shorter import syntax.
Only one person was specifically in favour of goldfire's proposal. I think this low number had more to do with the proposal not being presented very clearly than anything else, given how similar the two proposals are.
Edit: Some people argued for a more descriptive keyword than as (e.g. import Data.Map (Map) and as M (...) or import Data.Map (Map) andAs M (...)). These could be counted towards goldfire's proposal perhaps.
A few people were (strongly) against acowley's proposal, all citing Richard O'Keefe's mail.
reddit seemed firmly against acowley's proposal as well (the top comment has 12 votes and starts with "-1"). This is the reason I think we should proceed carefully here.

I don't think this is going to go anywhere without someone writing a proposal page on the wiki, with specifications of the 2 options and the above table, and then having another round of discussion on the mailinglist.

If one of you could get behind the other person's proposal, that would make things easier as well.

More explicitly, @acowley:

Could you please start a Proposal/ShortImports wiki page with a specification of your language extension?
What is your opinion on goldfire's alternative proposal (see ticket:10478#comment:100339 and ticket:10478#comment:106939)?

Trac field	Value
Version	7.10.1
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

Shorter import syntax

Child items 0

Activity