[Haskell-cafe] Proposal: Shorter Import Syntax

Wed Jun 3 19:49:02 UTC 2015

Thanks for providing the numbers -- it's always helpful to keep in mind how common an idiom is.

I would like to point out that my proposal *is* meant to be fully backward-compatible. I just didn't put the backward-compatible bits in the grammar I laid out, because I thought they would obscure the point. The existing syntax would remain, entirely unchanged.

Richard

On Jun 3, 2015, at 3:01 PM, Anthony Cowley <acowley at seas.upenn.edu> wrote:

> On Wed, Jun 3, 2015 at 1:43 PM, Richard Eisenberg <eir at cis.upenn.edu> 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 <adam at 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 at 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 at 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 at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> 
>>> 
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> 
>> 
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> 
>> 
>> 
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> 