[Haskell-cafe] Proposal: Shorter Import Syntax

Anthony Cowley acowley at seas.upenn.edu
Thu Jun 4 18:14:00 UTC 2015


Sorry, Yuras! I wanted to make sure the dissenting voices were heard.

The current vote count is ~28-4. It seems like we're on the precipice
of a fatal bike shedding, so I'm counting all the votes for keeping
"quantified" as negative (as that's what Richard stated for himself),
and trying to be conservative counting the +1's. I hope that's enough
of a majority.

To put things in perspective again, the Stackage package set has 10x
as many qualified imports as unqualified imports that use the "as"
keyword. The point here is to slightly smooth things out for the 10-1
majority case.

While I do appreciate that these two lines can potentially be mistaken
for each other,

import Map as M (fromList)
import Map (fromList) as M

I think the movement of the explicit import group is quite visibly
striking, and, as previously noted, you could misread the former every
time and only misunderstand 0.3% of import statements you read.

Preserving the "qualified" keyword is better than no change at all,
but is, I think, gratuitous preservation of a minor wart. Given the
support for the original proposal, I'd hate to snatch defeat from the
jaws of victory here.

Anthony


On Wed, Jun 3, 2015 at 3:53 PM, Yuras Shumovich <shumovichy at gmail.com> wrote:
> On Wed, 2015-06-03 at 13:15 -0400, Anthony Cowley wrote:
>> 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.
>
> Hello,
>
> You counted me as -1, but I'm not against the proposal. I just expressed
> my concerns in the my comment on Trac.
>
> Actually I'd prefer "import Foo as F(foo)" to import "foo" qualified.
> Too often I write such import by mistake (missing "qualified"), and get
> compilation error later. Unfortunately it will break code.
>
> Thanks,
> Yuras.
>
>>
>> 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
>
>


More information about the Haskell-Cafe mailing list