Re: [Haskell-cafe] Proposal: Shorter Import Syntax

On Wed, Jun 3, 2015 at 1:43 PM, Richard Eisenberg wrote:

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.

Calling this "awfully confusing" is dramatically overstating things. A quick grep over all of the Stackage package set sources suggests that the "import Foo as F (foo)" syntax is used in less than 0.3% of all import statements. If the rule that the "explicit import list is always imported unqualified" really is too confusing (even though it is the current rule), you could guess wrong every time and only misunderstand three out of a thousand imports you encounter in the wild. I think this is a tiny tail wagging an otherwise healthy dog. That we can get rid of the word "qualified" for a common case without breaking anything seems like a clear win to me. But I appreciate some people disagree, which is why I thought it was important to make the broad support visible rather than surprise anyone. If there is enough opposition (we're around 25-3 at the moment), we can let the sleeping dog lie. As to the alternative proposal, I'm less positive on it as it seems unnecessarily verbose given the original option, and the fact that, as presented, it breaks existing code makes it a non-starter. Anthony

--- 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 wrote:

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

On Wed, Jun 3, 2015 at 7:18 PM, Michael Snoyman 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 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

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