From hesselink at gmail.com  Tue Mar  1 12:16:06 2016
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 1 Mar 2016 13:16:06 +0100
Subject: GHC 8.0.1 status
In-Reply-To: <87wppqz26d.fsf@smart-cactus.org>
References: <87wppqz26d.fsf@smart-cactus.org>
Message-ID: <CAPeieQEpp2xpmfny41me+aWP3hKN=rXCEHZGvpSFZdfsBLyLLw@mail.gmail.com>

I've found what I believe to be a regression in GHC 8 rc2 [1], and the
wiki says to yell if I want to bring it to the attention of GHC
developers. So this is me yelling, I guess :) I'm not sure if this bug
is important enough to be included, but I think it would be good for
someone to look at it and make that call. It's at least breaking one
package that I maintain (but it can be worked around).

Erik

[1] https://ghc.haskell.org/trac/ghc/ticket/11662

On 27 February 2016 at 14:57, Ben Gamari <ben at well-typed.com> wrote:
> tl;dr. Stabilizing the ghc-8.0 is taking a bit longer than was anticipated.
>        The release schedule is being pushed back a bit.
>
>
> Hello everyone,
>
> As you likely know we are currently in the depths of the 8.0 release. In
> fact, under more ideal circumstances I would probably be cutting another
> release candidate right now instead of writing this email, in
> preparation for a final release next week or so.
>
> However, our world is far from ideal as evidenced by the number
> [1] of significant bugs present on the 8.0 branch. This isn't altogether
> unexpected; we knew we were taking a bit of a risk in merging so many
> high-impact patches in one release. However, we thought that given a
> longer-than-usual period between first-candidate and the final release,
> we'd have enough time to smooth out the wrinkles. Sadly, this has taken
> a bit longer than we anticipated.
>
> Of course, the last thing we want is to push a known buggy release out
> the door. Consequently, we won't be delivering the 8.0.1 release next
> week as originally planned. Instead, we'll be pushing the release back
> by about three weeks. This will give developers a bit more breathing
> room in which to work out the remaining issues. Hopefully in a few weeks
> the tree will be in such a state that we can push out yet another
> candidate which, with luck, will be the last before the release.
>
> If you'd like to expedite the process (and have fun in the process), you
> could do worse than to having a look at Trac [1], choosing a bug of your
> liking, and trying your hand at solving it.
>
> Thanks to everyone who has contributed to this effort thusfar.
> If you have any questions about the release process or how you can help,
> don't hesistate to ask.
>
> Cheers,
>
> - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From ben at well-typed.com  Tue Mar  1 12:24:55 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 01 Mar 2016 13:24:55 +0100
Subject: GHC 8.0.1 status
In-Reply-To: <CAPeieQEpp2xpmfny41me+aWP3hKN=rXCEHZGvpSFZdfsBLyLLw@mail.gmail.com>
References: <87wppqz26d.fsf@smart-cactus.org>
 <CAPeieQEpp2xpmfny41me+aWP3hKN=rXCEHZGvpSFZdfsBLyLLw@mail.gmail.com>
Message-ID: <87k2lmz8q0.fsf@smart-cactus.org>

Erik Hesselink <hesselink at gmail.com> writes:

> I've found what I believe to be a regression in GHC 8 rc2 [1], and the
> wiki says to yell if I want to bring it to the attention of GHC
> developers. So this is me yelling, I guess :) I'm not sure if this bug
> is important enough to be included, but I think it would be good for
> someone to look at it and make that call. It's at least breaking one
> package that I maintain (but it can be worked around).
>
Thanks Erik!

Indeed this looks to me to be a regression.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160301/8b4a0bb3/attachment.sig>

From jrw at pobox.com  Fri Mar 18 18:27:34 2016
From: jrw at pobox.com (John Williams)
Date: Fri, 18 Mar 2016 11:27:34 -0700
Subject: idea: tool to suggest adding imports
Message-ID: <CAEdRJLDOhu71DRrPq1pBq1-qRVgca7=R_HD1ky2pniiFgMouBg@mail.gmail.com>

I have an idea for a tool I'd like to implement, and I'm looking for advice
on the best way to do it.

Ideally, I want to write an Emacs extension where, if I'm editing Haskell
code and I try to use a symbol that's not defined or imported, it will try
to automatically add an appropriate import for the symbol. If instance, if
I have "import Data.Maybe (isNothing)" in my module, and I try to call
"isJust", the extension would automatically change the import to "import
Data.Maybe (isJust, isNothing)".

The Emacs part is easy, but the Haskell part has me kind of lost. Basically
I want to figure out how to heuristically resolve a name, using an existing
set of imports as hints and constraints. The main heuristic I'd like to
implement is that, if some symbols are imported from a module M, consider
importing additional symbols from M. A more advanced heuristic might
suggest that if a symbol is exported from a module M in a visible package
P, the symbol should be imported from M. Finally, if a symbol is exported
by a module in the Haskell platform, I'd like to suggest adding the
relevant package as a dependency in the .cabal and/or stack.yaml file, and
adding an import for it in the .hs file.

Here are some implementation options I'm considering:

1. Add a ghci command to implement my heuristics directly, since ghc
already understands modules, packages and import statements.
2. Load a modified version of the source file into ghci where imports like
"import M (...)" are replaced with "import M", and parse the error messages
about ambiguous symbols.
3. Write a separate tool that reads Haskell imports and duplicates ghc and
cabal's name resolution mechanisms.
4. Write a tool that reads Haskell imports and suggests imports from a list
of commonly imported symbols, ignoring which packages are actually visible.

Right now the options that look best to me are 2 and 4, because the don't
require me to understand or duplicate big parts of ghc, but if modifying
ghc isn't actually that hard, then maybe 1 is the way to go. Option 3 might
be a good way to go if there are libraries I can use to do the hard work
for me.

Any thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160318/77936e9b/attachment.html>

From harendra.kumar at gmail.com  Fri Mar 18 19:12:05 2016
From: harendra.kumar at gmail.com (Harendra Kumar)
Date: Sat, 19 Mar 2016 00:42:05 +0530
Subject: idea: tool to suggest adding imports
In-Reply-To: <CAEdRJLDOhu71DRrPq1pBq1-qRVgca7=R_HD1ky2pniiFgMouBg@mail.gmail.com>
References: <CAEdRJLDOhu71DRrPq1pBq1-qRVgca7=R_HD1ky2pniiFgMouBg@mail.gmail.com>
Message-ID: <CAPW+kkaPPhOhiVS87Bubd5GhmBfK=LjWqbYF2q3gVAnGeyMvrA@mail.gmail.com>

That's cool, I'd love to have that feature in my editor. Have you seen this:

https://hackage.haskell.org/package/halberd

The readme says:

---cut---

Halberd is a tool to help you add missing imports to your Haskell source
files. With it, you can write your source without imports, call Halberd,
and just paste in the import lines.

Currently, it tries to automatically choose an import if there is a single
sensible option. If it can't, it will prompt you with a simple menu. After
running, it prints the imports, which you need to copy manually. Editor
integration is planned.

---cut---


I have been thinking of exactly the same problem. That's how found this. I
have not tried it yet but this could be a starting point even if its not
working perfectly. In the best case you will have to just do the editor
integration part.

-harendra

On 18 March 2016 at 23:57, John Williams <jrw at pobox.com> wrote:

> I have an idea for a tool I'd like to implement, and I'm looking for
> advice on the best way to do it.
>
> Ideally, I want to write an Emacs extension where, if I'm editing Haskell
> code and I try to use a symbol that's not defined or imported, it will try
> to automatically add an appropriate import for the symbol. If instance, if
> I have "import Data.Maybe (isNothing)" in my module, and I try to call
> "isJust", the extension would automatically change the import to "import
> Data.Maybe (isJust, isNothing)".
>
> The Emacs part is easy, but the Haskell part has me kind of lost.
> Basically I want to figure out how to heuristically resolve a name, using
> an existing set of imports as hints and constraints. The main heuristic I'd
> like to implement is that, if some symbols are imported from a module M,
> consider importing additional symbols from M. A more advanced heuristic
> might suggest that if a symbol is exported from a module M in a visible
> package P, the symbol should be imported from M. Finally, if a symbol is
> exported by a module in the Haskell platform, I'd like to suggest adding
> the relevant package as a dependency in the .cabal and/or stack.yaml file,
> and adding an import for it in the .hs file.
>
> Here are some implementation options I'm considering:
>
> 1. Add a ghci command to implement my heuristics directly, since ghc
> already understands modules, packages and import statements.
> 2. Load a modified version of the source file into ghci where imports like
> "import M (...)" are replaced with "import M", and parse the error messages
> about ambiguous symbols.
> 3. Write a separate tool that reads Haskell imports and duplicates ghc and
> cabal's name resolution mechanisms.
> 4. Write a tool that reads Haskell imports and suggests imports from a
> list of commonly imported symbols, ignoring which packages are actually
> visible.
>
> Right now the options that look best to me are 2 and 4, because the don't
> require me to understand or duplicate big parts of ghc, but if modifying
> ghc isn't actually that hard, then maybe 1 is the way to go. Option 3 might
> be a good way to go if there are libraries I can use to do the hard work
> for me.
>
> Any thoughts?
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160319/b0ceacbb/attachment.html>

From ezyang at mit.edu  Fri Mar 18 22:16:07 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Fri, 18 Mar 2016 15:16:07 -0700
Subject: idea: tool to suggest adding imports
In-Reply-To: <CAEdRJLDOhu71DRrPq1pBq1-qRVgca7=R_HD1ky2pniiFgMouBg@mail.gmail.com>
References: <CAEdRJLDOhu71DRrPq1pBq1-qRVgca7=R_HD1ky2pniiFgMouBg@mail.gmail.com>
Message-ID: <1458339046-sup-7400@sabre>

Hello John,

In my opinion, the big question is whether or not your Emacs extension
should know how to build your Haskell project.  Without this knowledge,
(1) and (3) are non-starters, since you have to pass the right set of
-package flags to GHC to get the process started.

If you do assume you have this knowledge, then I think writing a
little stub program using the GHC API (the best fit is the recent
frontend plugins feature:
https://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/users_guide/extending_ghc.html#frontend-plugins
because it will handle command line parsing for you; unfortunately, it
will also limit you to GHC 8 only) is your best bet.

Edward

Excerpts from John Williams's message of 2016-03-18 11:27:34 -0700:
> I have an idea for a tool I'd like to implement, and I'm looking for advice
> on the best way to do it.
> 
> Ideally, I want to write an Emacs extension where, if I'm editing Haskell
> code and I try to use a symbol that's not defined or imported, it will try
> to automatically add an appropriate import for the symbol. If instance, if
> I have "import Data.Maybe (isNothing)" in my module, and I try to call
> "isJust", the extension would automatically change the import to "import
> Data.Maybe (isJust, isNothing)".
> 
> The Emacs part is easy, but the Haskell part has me kind of lost. Basically
> I want to figure out how to heuristically resolve a name, using an existing
> set of imports as hints and constraints. The main heuristic I'd like to
> implement is that, if some symbols are imported from a module M, consider
> importing additional symbols from M. A more advanced heuristic might
> suggest that if a symbol is exported from a module M in a visible package
> P, the symbol should be imported from M. Finally, if a symbol is exported
> by a module in the Haskell platform, I'd like to suggest adding the
> relevant package as a dependency in the .cabal and/or stack.yaml file, and
> adding an import for it in the .hs file.
> 
> Here are some implementation options I'm considering:
> 
> 1. Add a ghci command to implement my heuristics directly, since ghc
> already understands modules, packages and import statements.
> 2. Load a modified version of the source file into ghci where imports like
> "import M (...)" are replaced with "import M", and parse the error messages
> about ambiguous symbols.
> 3. Write a separate tool that reads Haskell imports and duplicates ghc and
> cabal's name resolution mechanisms.
> 4. Write a tool that reads Haskell imports and suggests imports from a list
> of commonly imported symbols, ignoring which packages are actually visible.
> 
> Right now the options that look best to me are 2 and 4, because the don't
> require me to understand or duplicate big parts of ghc, but if modifying
> ghc isn't actually that hard, then maybe 1 is the way to go. Option 3 might
> be a good way to go if there are libraries I can use to do the hard work
> for me.
> 
> Any thoughts?

From qdunkan at gmail.com  Fri Mar 18 22:51:48 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Fri, 18 Mar 2016 15:51:48 -0700
Subject: idea: tool to suggest adding imports
In-Reply-To: <CAEdRJLDOhu71DRrPq1pBq1-qRVgca7=R_HD1ky2pniiFgMouBg@mail.gmail.com>
References: <CAEdRJLDOhu71DRrPq1pBq1-qRVgca7=R_HD1ky2pniiFgMouBg@mail.gmail.com>
Message-ID: <CACbaDy4tivcu1aooDsVdiXFNrYTJOK1d7Q+nT_E=JL0WkRjwMA@mail.gmail.com>

I did this about 5 or 6 years ago for vim, and I'm so used to it I
wouldn't want to live without it.  So I definitely recommend just
doing it.  It was surprisingly easy to implement, it only took a few
hours, and then a day or so to refine the details.

I used haskell-src-exts for parsing and ghc-pkg for all visible
modules.  By far the slowest part is haskell-src-exts.  I have some
basic local preferences to resolve name clashes, and with that using
the global package list has never been much of a problem.  If it were
I could use a local sandbox.

I don't have any fancy suggestion list, just pick the most likely.  I
edit the import by hand if it was wrong, which is rare enough that I
don't mind.

On Fri, Mar 18, 2016 at 11:27 AM, John Williams <jrw at pobox.com> wrote:
> I have an idea for a tool I'd like to implement, and I'm looking for advice
> on the best way to do it.
>
> Ideally, I want to write an Emacs extension where, if I'm editing Haskell
> code and I try to use a symbol that's not defined or imported, it will try
> to automatically add an appropriate import for the symbol. If instance, if I
> have "import Data.Maybe (isNothing)" in my module, and I try to call
> "isJust", the extension would automatically change the import to "import
> Data.Maybe (isJust, isNothing)".
>
> The Emacs part is easy, but the Haskell part has me kind of lost. Basically
> I want to figure out how to heuristically resolve a name, using an existing
> set of imports as hints and constraints. The main heuristic I'd like to
> implement is that, if some symbols are imported from a module M, consider
> importing additional symbols from M. A more advanced heuristic might suggest
> that if a symbol is exported from a module M in a visible package P, the
> symbol should be imported from M. Finally, if a symbol is exported by a
> module in the Haskell platform, I'd like to suggest adding the relevant
> package as a dependency in the .cabal and/or stack.yaml file, and adding an
> import for it in the .hs file.
>
> Here are some implementation options I'm considering:
>
> 1. Add a ghci command to implement my heuristics directly, since ghc already
> understands modules, packages and import statements.
> 2. Load a modified version of the source file into ghci where imports like
> "import M (...)" are replaced with "import M", and parse the error messages
> about ambiguous symbols.
> 3. Write a separate tool that reads Haskell imports and duplicates ghc and
> cabal's name resolution mechanisms.
> 4. Write a tool that reads Haskell imports and suggests imports from a list
> of commonly imported symbols, ignoring which packages are actually visible.
>
> Right now the options that look best to me are 2 and 4, because the don't
> require me to understand or duplicate big parts of ghc, but if modifying ghc
> isn't actually that hard, then maybe 1 is the way to go. Option 3 might be a
> good way to go if there are libraries I can use to do the hard work for me.
>
> Any thoughts?
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>

From alexander at plaimi.net  Sat Mar 19 15:12:38 2016
From: alexander at plaimi.net (Alexander Berntsen)
Date: Sat, 19 Mar 2016 16:12:38 +0100
Subject: idea: tool to suggest adding imports
In-Reply-To: <CACbaDy4tivcu1aooDsVdiXFNrYTJOK1d7Q+nT_E=JL0WkRjwMA@mail.gmail.com>
References: <CAEdRJLDOhu71DRrPq1pBq1-qRVgca7=R_HD1ky2pniiFgMouBg@mail.gmail.com>
 <CACbaDy4tivcu1aooDsVdiXFNrYTJOK1d7Q+nT_E=JL0WkRjwMA@mail.gmail.com>
Message-ID: <56ED6C66.3060307@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 18/03/16 23:51, Evan Laforge wrote:
> I did this about 5 or 6 years ago for vim, and I'm so used to it I 
> wouldn't want to live without it.
Is your plug-in free software? Do you have a link to it? It sounds
very useful to us vim users.

- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJW7WxmAAoJENQqWdRUGk8BkvsQAIf+1UyESa5YqdXAgPMt33E0
iyEudGMdh86R8WboYf1HmI4LFYdVikKpA8NSEEnc41PbcEsTp0qUjcQ82mcfR+Lh
zHwuZkPOQmlsTIcnOMerLHi+DjgSZRuEXwurBHp7MEpPxqR8nW2eGSq3s0vc4XDv
gUHhqjZXfRs19XhbzBrDiMjD/UeSWgPljfy9VHE6l4yXtw4QwcfaI/RAnl1SvI+2
POddyKemMKtbNIq9zl7H25PhxYSjC0fdgu6OGByRpOu/SvL4WP7tXNEM0Oo/y+Q8
VL6vCCbCYiyhJWPiHJIwz2RJ5EUw973owLuHtazZwQdaKHARILqcdN5lNBza9wHU
+zISRZ5Qsz5VCk7AQNXmBLssTJJAVqWr1lgHpj675n7uS6WjYdVDzNm3s8pG0m2F
SipjVd7HRWdiA0+Eej/Afbuiltd7NDEeAtIlVsCvFX0annotY6I0ne9ZpoL5JWMi
tos+APpoaSxwyiwYdx7+IoBYg5ZRZYCevg09aLR6ehGv8a14xqgZut+LPBjgZ7aU
3PfNlUNLRz39PcJXLR0GqxV2z8f4KD7EirCFj2IPW/yYQmw44ZcvXe96v19IHkiX
yn08XLab/u1Xop4cBOBh5YgHrrjqhRJ6mATsVXFYOK1o2IsOO2rbv+CnJrcXRZxc
9gFDrfsG0EvjGNkR5VHP
=wtXA
-----END PGP SIGNATURE-----

From qdunkan at gmail.com  Sat Mar 19 19:08:49 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Sat, 19 Mar 2016 12:08:49 -0700
Subject: idea: tool to suggest adding imports
In-Reply-To: <56ED6C66.3060307@plaimi.net>
References: <CAEdRJLDOhu71DRrPq1pBq1-qRVgca7=R_HD1ky2pniiFgMouBg@mail.gmail.com>
 <CACbaDy4tivcu1aooDsVdiXFNrYTJOK1d7Q+nT_E=JL0WkRjwMA@mail.gmail.com>
 <56ED6C66.3060307@plaimi.net>
Message-ID: <CACbaDy5B_8AJ0hHsb+PrEOmf2J_xE9fNrCFmZh4J4fm2s9ExWQ@mail.gmail.com>

On Sat, Mar 19, 2016 at 8:12 AM, Alexander Berntsen
<alexander at plaimi.net> wrote:
> On 18/03/16 23:51, Evan Laforge wrote:
>> I did this about 5 or 6 years ago for vim, and I'm so used to it I
>> wouldn't want to live without it.
> Is your plug-in free software? Do you have a link to it? It sounds
> very useful to us vim users.

The catch is that it uses qualified imports, which makes everything
easy.  If you're still interested, it's fix-imports on hackage.  There
are lots of others too, but I haven't tried them.

From hesselink at gmail.com  Sun Mar 20 11:57:11 2016
From: hesselink at gmail.com (Erik Hesselink)
Date: Sun, 20 Mar 2016 12:57:11 +0100
Subject: idea: tool to suggest adding imports
In-Reply-To: <CAPW+kkaPPhOhiVS87Bubd5GhmBfK=LjWqbYF2q3gVAnGeyMvrA@mail.gmail.com>
References: <CAEdRJLDOhu71DRrPq1pBq1-qRVgca7=R_HD1ky2pniiFgMouBg@mail.gmail.com>
 <CAPW+kkaPPhOhiVS87Bubd5GhmBfK=LjWqbYF2q3gVAnGeyMvrA@mail.gmail.com>
Message-ID: <CAPeieQE46swU+5SLWgWQ3qP8w-GLOuOQwzYnrtHz3xTbmCb5pg@mail.gmail.com>

I wrote halberd a while ago. It was mostly as an example of using the
haskell-names and haskell-packages packges (combined with
haskell-src-exts) that Roman Cheplyaka was working on at the time,
combined with a useful tool that I wanted for myself. The downside is
that haskell-packages doesn't use the same package database as ghc, so
you had to compile the packages twice: once with ghc, and once with
haskell-packages. That made the task of actually integrating it with
an editor in a useful way for large projects seem pretty hairy, so I
didn't continue working on it. Later there was a big API change in
haskell-names that I never took the time to support, so it currently
doesn't support the newest versions of its dependencies.

Let me know if you (or anyone else) wants to work on it or rip out
useful parts. Perhaps I can help out a bit.

Regards,

Erik

On 18 March 2016 at 20:12, Harendra Kumar <harendra.kumar at gmail.com> wrote:
> That's cool, I'd love to have that feature in my editor. Have you seen this:
>
> https://hackage.haskell.org/package/halberd
>
> The readme says:
>
> ---cut---
>
> Halberd is a tool to help you add missing imports to your Haskell source
> files. With it, you can write your source without imports, call Halberd, and
> just paste in the import lines.
>
> Currently, it tries to automatically choose an import if there is a single
> sensible option. If it can't, it will prompt you with a simple menu. After
> running, it prints the imports, which you need to copy manually. Editor
> integration is planned.
>
> ---cut---
>
>
> I have been thinking of exactly the same problem. That's how found this. I
> have not tried it yet but this could be a starting point even if its not
> working perfectly. In the best case you will have to just do the editor
> integration part.
>
>
> -harendra
>
> On 18 March 2016 at 23:57, John Williams <jrw at pobox.com> wrote:
>>
>> I have an idea for a tool I'd like to implement, and I'm looking for
>> advice on the best way to do it.
>>
>> Ideally, I want to write an Emacs extension where, if I'm editing Haskell
>> code and I try to use a symbol that's not defined or imported, it will try
>> to automatically add an appropriate import for the symbol. If instance, if I
>> have "import Data.Maybe (isNothing)" in my module, and I try to call
>> "isJust", the extension would automatically change the import to "import
>> Data.Maybe (isJust, isNothing)".
>>
>> The Emacs part is easy, but the Haskell part has me kind of lost.
>> Basically I want to figure out how to heuristically resolve a name, using an
>> existing set of imports as hints and constraints. The main heuristic I'd
>> like to implement is that, if some symbols are imported from a module M,
>> consider importing additional symbols from M. A more advanced heuristic
>> might suggest that if a symbol is exported from a module M in a visible
>> package P, the symbol should be imported from M. Finally, if a symbol is
>> exported by a module in the Haskell platform, I'd like to suggest adding the
>> relevant package as a dependency in the .cabal and/or stack.yaml file, and
>> adding an import for it in the .hs file.
>>
>> Here are some implementation options I'm considering:
>>
>> 1. Add a ghci command to implement my heuristics directly, since ghc
>> already understands modules, packages and import statements.
>> 2. Load a modified version of the source file into ghci where imports like
>> "import M (...)" are replaced with "import M", and parse the error messages
>> about ambiguous symbols.
>> 3. Write a separate tool that reads Haskell imports and duplicates ghc and
>> cabal's name resolution mechanisms.
>> 4. Write a tool that reads Haskell imports and suggests imports from a
>> list of commonly imported symbols, ignoring which packages are actually
>> visible.
>>
>> Right now the options that look best to me are 2 and 4, because the don't
>> require me to understand or duplicate big parts of ghc, but if modifying ghc
>> isn't actually that hard, then maybe 1 is the way to go. Option 3 might be a
>> good way to go if there are libraries I can use to do the hard work for me.
>>
>> Any thoughts?
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>

From alexander at plaimi.net  Sun Mar 20 13:54:37 2016
From: alexander at plaimi.net (Alexander Berntsen)
Date: Sun, 20 Mar 2016 14:54:37 +0100
Subject: idea: tool to suggest adding imports
In-Reply-To: <CACbaDy5B_8AJ0hHsb+PrEOmf2J_xE9fNrCFmZh4J4fm2s9ExWQ@mail.gmail.com>
References: <CAEdRJLDOhu71DRrPq1pBq1-qRVgca7=R_HD1ky2pniiFgMouBg@mail.gmail.com>
 <CACbaDy4tivcu1aooDsVdiXFNrYTJOK1d7Q+nT_E=JL0WkRjwMA@mail.gmail.com>
 <56ED6C66.3060307@plaimi.net>
 <CACbaDy5B_8AJ0hHsb+PrEOmf2J_xE9fNrCFmZh4J4fm2s9ExWQ@mail.gmail.com>
Message-ID: <56EEAB9D.40708@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 19/03/16 20:08, Evan Laforge wrote:
> The catch is that it uses qualified imports, which makes
> everything easy.  If you're still interested, it's fix-imports on
> hackage.  There are lots of others too, but I haven't tried them.
Ah. I generally want explicit imports. But I'll have a look nonetheless.

- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJW7qubAAoJENQqWdRUGk8B39EQAKRTt43Tv+t8iIKZnQVxnJ93
/karzj0/cxte0cAH3pVnOvk3Zqu2LHf3DhmQepR5LY4UmSoxLDUguS+g220WgQjh
CdMdMzlC6u4HkhKzhGg6Cp46vya7GGMVioSJ06qKM6Y5fSfEC6e225J6MuGpDsCW
097vkCwfkPwLmz64vaU3nsGZNmrUeZV9e9zHZhKRNnylQzw51gWNOS47vYKnuDe2
uLxaoSqu5Lj925tb0U6UzFdTfXItiaARUTauN9x1ukDNGVgI2Duas6dHmv4fhRWq
FdA6Xv5sR2QdcUOIW9TczHGvFyete37hdk/S1RUF1br9Qk0k7oZUJSYU8pn3riTj
s1i244yzgpK/+fQ+KznD3YUb2LLrxB6Njv+911w6Ld1r71CT+sKsIr0WUqq8cE2p
99RxWqgby1iOQBb8hICY630kF0oPItS0JiZiujY0hvPPjEOmAiZ/cpJAIxhr3aom
11uLG/8rLQAIF3E5sHLBefwa83oB6NhoO1J0ZNW53q0gg3o6LY59R2ijfkrPfGB0
rfhhzXBH6bj51Nj/Xri2GFDGN1f+fC1sAUE0s7yIZ4XQ5d1ncOU8N1G55+tvw6wC
/r0h4OUN1AajU2KYjgbyqTz/0Qc+juAthMgZypT5Exww7qwZdQuYbCIDjLVx/J2S
UcGW3PLEGmzaIFRl5xwz
=1YHj
-----END PGP SIGNATURE-----

From daniel.trstenjak at gmail.com  Sun Mar 20 17:48:55 2016
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Sun, 20 Mar 2016 18:48:55 +0100
Subject: idea: tool to suggest adding imports
In-Reply-To: <CAEdRJLDOhu71DRrPq1pBq1-qRVgca7=R_HD1ky2pniiFgMouBg@mail.gmail.com>
References: <CAEdRJLDOhu71DRrPq1pBq1-qRVgca7=R_HD1ky2pniiFgMouBg@mail.gmail.com>
Message-ID: <20160320174855.GA5332@brick>


Hi John,

for the Haskell source modification part I've written hsimport[1].

For finding a certain symbol in the moduls of the dependencies of
a project, there's the 'findsymbol' command of a more recent hdevtools[2].

There's also vim-hsimport[3] combining the two.

Greetings,
Daniel

[1] https://hackage.haskell.org/package/hsimport
[2] https://hackage.haskell.org/package/hdevtools
[3] https://github.com/dan-t/vim-hsimport

From lemming at henning-thielemann.de  Wed Mar 23 13:16:00 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 23 Mar 2016 14:16:00 +0100 (CET)
Subject: Warn about unwanted instances in a modular way
Message-ID: <alpine.DEB.2.02.1603222002050.8382@sputnik>


I like to propose the following way to warn about instances that are 
unwanted by some programmers. First step is to mark the instances at their 
definition site like so:

{-# WARN_INSTANCE tuple #-}
instance Foldable ((,) a) where ...

{-# WARN_INSTANCE tuple #-}
instance Functor ((,) a) where ...

{-# WARN_INSTANCE tuple #-}
instance Foldable ((,,) a b) where ...

{-# WARN_INSTANCE tuple #-}
instance Functor ((,,) a b) where ...


This way, all the above instances are collected in an instance group 
labelled 'tuple'. At the use sites we introduce a GHC warning option like 
-fwarn-instance=tuple. This warns about any place where any of the 'tuple' 
instances is used. We can either place

    GHC-Options: -fwarn-instance=tuple

in a Cabal package description in order to issue warnings in a whole 
package or we can put

    {-# OPTIONS_GHC -fwarn-instance=tuple #-}

at the top of a module in order to enable the warning per module.

Another candidate for an instance group might be 'numeric' for numeric 
instances of functions and tuples in the NumInstances package.

What does it mean to use an instance? I would say, if omitting an instance 
X Y would lead to a "missing instance" type error at place Z in a module, 
then instance X Y is used at place Z.

There might be an even more restrictive option like:
    -fforbid-instance=tuple

This would not only warn about an instance usage, but it would cause a 
type error. Essentially it should treat all 'tuple' instances as if they 
were not defined. (Other instances might depend on 'tuple' instances and 
if the 'tuple' instances weren't there the compiler would not even reach 
the current module. I do not know, whether this case needs special 
treatment. We might require that any instance depending on 'tuple' must be 
added to the 'tuple' group as well or it might be added automatically.)
  The advantage of a type error is that we see all problems from 'tuple' 
instances also in the presence of other type errors. Warnings would only 
show up after a module is otherwise type correct.

This solution requires cooperation of the instance implementor. Would that 
work in practice? Otherwise we must think about ways to declare instance 
groups independently from the instance declaration and we get the problem 
of bringing the instance group names into the scope of the importing 
module.

A separate discussion must be held on whether -fwarn-instance=tuple should 
be part of -Wall. I think that people should be warned about 'tuple' 
instances early because they won't expect that there is a trap when using 
'length' and 'maximum' and so on.

One might also think about generalizations, e.g. whether

    {-# WARN_INSTANCE tuple, functor #-}

should be allowed in order to put an instance in several groups or whether 
there should be a way to compose a group from subgroups.

Another topic would be a form of instance group disambiguation. Instance 
groups might be qualified with module or package names. I think package 
names are more appropriate, like so:
    -fwarn-instance=base:tuple