[Haskell-cafe] Proposal: Shorter Import Syntax

Anthony Cowley acowley at seas.upenn.edu
Wed Jun 3 19:01:55 UTC 2015


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
>


More information about the Haskell-Cafe mailing list