<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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 (<a href="https://ghc.haskell.org/trac/ghc/ticket/10478#comment:3">https://ghc.haskell.org/trac/ghc/ticket/10478#comment:3</a>), which I paste here for ease of access.</div><div><br></div><div>---</div><div><div>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</div><div><br></div><div>{{{</div><div>import Data.Map (Map) as M    -- (1)</div><div>}}}</div><div><br></div><div>a very different meaning from</div><div><br></div><div>{{{</div><div>import Data.Map as M (Map)    -- (2)</div><div>}}}</div><div><br></div><div>(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`.</div><div>Having these two coexist seems like we're asking users to be confused.</div><div><br></div><div>What about</div><div><br></div><div>{{{</div><div>import Data.Map (Map)</div><div>  qualified as M *</div><div>}}}</div><div><br></div><div>?</div><div><br></div><div>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.</div><div><br></div><div>{{{</div><div>import_statement  ::= 'import' module_name maybe_name_list import_specifiers</div><div>module_name       ::= ...</div><div>maybe_name_list   ::= name_list | <empty></div><div>name_list         ::= '(' names ')' | '*'</div><div>import_specifiers ::= <empty> | import_specifier import_specifiers</div><div>import_specifier  ::= 'hiding' name_list | qualified_spec name_list</div><div>qualified_spec    ::= 'qualified' | 'qualified' 'as' name</div><div>}}}</div><div><br></div><div>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.</div><div><br></div><div>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`.</div><div><br></div><div>The special `name_list` `*` (note that it is ''not'' in parentheses, to avoid ambiguity) means "all names".</div><div><br></div><div>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:</div><div><br></div><div>{{{</div><div>import qualified Foo       -->  import Foo qualified *</div><div>import qualified Bar as B  -->  import Bar qualified as B *</div><div>import Baz hiding (wurble) -->  import Baz hiding (wurble)</div><div>}}}</div><div><br></div><div>Thoughts?</div></div><div><br></div><div>Richard</div><br><div><div>On Jun 3, 2015, at 1:31 PM, Adam Bergmark <<a href="mailto:adam@bergmark.nl">adam@bergmark.nl</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">+1, I thought of the exact same syntax at some point.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 3, 2015 at 7:18 PM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<br></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 3, 2015 at 8:15 PM Anthony Cowley <<a href="mailto:acowley@seas.upenn.edu" target="_blank">acowley@seas.upenn.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Everyone,<br>
<br>
I didn't think this would see any resistance as it doesn't break<br>
anything, but this is the internet, so, if you haven't already, take a<br>
look at this GHC feature request<br>
<<a href="https://ghc.haskell.org/trac/ghc/ticket/10478" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/10478</a>><br>
<br>
The idea is that rather than writing,<br>
<br>
import Data.Map (Map)<br>
import qualified Data.Map as M<br>
<br>
you could instead write,<br>
<br>
import Data.Map (Map) as M<br>
<br>
The Map identifier would imported unqualified, while M would be<br>
introduced as an alias for the qualified import of Data.Map.<br>
<br>
Note that, currently, following a parenthesized group with the "as"<br>
keyword is a parse error. So allowing this syntax would not affect any<br>
currently working programs.<br>
<br>
I've mentioned this proposal before and gotten good response, so I<br>
finally wrote it up last night after people on IRC responded<br>
positively to it. As well as IRC and trac, I put the link up on<br>
Twitter to get it in front of a large audience, and here's what we<br>
have after a bit over 12 hours (not counting the handful of supporters<br>
in IRC):<br>
<br>
+20<br>
-2<br>
<br>
You can see the tweet at<br>
<<a href="https://twitter.com/a_cowley/status/605909841148702720" target="_blank">https://twitter.com/a_cowley/status/605909841148702720</a>><br>
<br>
I'll try to summarize the two negative votes: 1) This isn't that big a<br>
burden, and we should instead focus on controlled export of class<br>
instances; and 2) We should instead focus on exporting name spaces,<br>
and that the ordering of parentheses and the "as" keyword is too close<br>
to the existing "import Foo as F(foo)" syntax.<br>
<br>
Since there are these negative votes, I think it best if as many<br>
people as possible at least see the proposal so the GHC developers can<br>
get a better sense for the overall response.<br>
<br>
Anthony<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>Haskell-Cafe mailing list<br><a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe<br></blockquote></div><br></body></html>