I have to say I'm a big -1 on the proposed syntax -- it's awfully confusing to have the import list mean something entirely different before the `as` compared to after the `as`. I proposed a different syntax on the ticket (https://ghc.haskell.org/trac/ghc/ticket/10478#comment:3), which I paste here for ease of access.

---
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_spec`s, then all names would be imported unqualified. If it is omitted and there are one or more `qualified_spec`s, 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?

Richard

On Jun 3, 2015, at 1:31 PM, Adam Bergmark <adam@bergmark.nl> wrote:

+1, I thought of the exact same syntax at some point.

On Wed, Jun 3, 2015 at 7:18 PM, Michael Snoyman <michael@snoyman.com> wrote:
That's nifty. Just about every module in the project I'm working on now has two lines like the former (and the same for Set). I like the new syntax, +1.

On Wed, Jun 3, 2015 at 8:15 PM Anthony Cowley <acowley@seas.upenn.edu> wrote:
Hi Everyone,

I didn't think this would see any resistance as it doesn't break
anything, but this is the internet, so, if you haven't already, take a
look at this GHC feature request
<https://ghc.haskell.org/trac/ghc/ticket/10478>

The idea is that rather than writing,

import Data.Map (Map)
import qualified Data.Map as M

you could instead write,

import Data.Map (Map) as M

The Map identifier would imported unqualified, while M would be
introduced as an alias for the qualified import of Data.Map.

Note that, currently, following a parenthesized group with the "as"
keyword is a parse error. So allowing this syntax would not affect any
currently working programs.

I've mentioned this proposal before and gotten good response, so I
finally wrote it up last night after people on IRC responded
positively to it. As well as IRC and trac, I put the link up on
Twitter to get it in front of a large audience, and here's what we
have after a bit over 12 hours (not counting the handful of supporters
in IRC):

+20
-2

You can see the tweet at
<https://twitter.com/a_cowley/status/605909841148702720>

I'll try to summarize the two negative votes: 1) This isn't that big a
burden, and we should instead focus on controlled export of class
instances; and 2) We should instead focus on exporting name spaces,
and that the ordering of parentheses and the "as" keyword is too close
to the existing "import Foo as F(foo)" syntax.

Since there are these negative votes, I think it best if as many
people as possible at least see the proposal so the GHC developers can
get a better sense for the overall response.

Anthony
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe