Please review #500: Add implicit import proposal, Shepherd: Baldur

older
GHC Proposals session at Haskell...

Joachim Breitner

5 May 2022 5 May '22

5:09 a.m.

Dear Committee, Add implicit import proposal has been submitted by Tristan de Cacqueray This is an interesting one: At first glance it looks quite un- haskellish, but it’s hard to poing out what’s, if anything, is wrong with it. I expect that the discussion will revolve not so much about technical issues, but more about best practices and our vision for Haskell’s look and feel. https://github.com/ghc-proposals/ghc-proposals/pull/500 https://github.com/TristanCacqueray/ghc-proposals/blob/implicit-import/propo... I suggest that Baldur, as our newest committee member, gets to shepherd this one. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Show replies by date

Joachim Breitner

1 Aug 1 Aug

2:45 a.m.

New subject: Please review #500: Add implicit import proposal, New Shepherd: Simon M.

Dear Committee, Add implicit import proposal has been submitted by Tristan de Cacqueray This is an interesting one: At first glance it looks quite un- haskellish, but it’s hard to poing out what’s, if anything, is wrong with it. I expect that the discussion will revolve not so much about technical issues, but more about best practices and our vision for Haskell’s look and feel. https://github.com/ghc-proposals/ghc-proposals/pull/500 https://github.com/TristanCacqueray/ghc-proposals/blob/implicit-import/propo... I originally assigned this to Baldur in May, but we haven't heard from you. To be considerate of the proposal author’s motivation, I’d like to re-assign this to Simon Marlow. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Simon Marlow

28 Aug 28 Aug

10:40 a.m.

New subject: Please review #500: Add implicit import proposal, New Shepherd: Simon M.

Apologies for the delay here, holidays and then a large backlog... As a reminder, this proposal would let you use qualified names like Data.Trace.trace without adding an explicit import. I've reviewed the whole comment section of the proposal, but I'm finding it difficult to arrive at a clear recommendation. Some points: - There's a certain amount of convenience enabled by the extension, for sure. And other languages (OCaml, Rust) have a similar feature. But - There are compile-time performance implications that are as-yet unmeasured. I've asked for more data on this in the github thread. - A strong argument against (in my opinion) is that tooling could do this automatically, rendering this extension redundant. HLS doesn't currently insert imports for qualified names automatically, but couldn't it? Other language servers do this kind of thing (e.g. Python) - The behaviour with respect to instances is a little too implicit. Removing a qualified identifier might eliminate an implicit import and thus hide some instances, causing the compiler to reject the module. I'm personally leaning towards rejection, but I don't feel strongly enough to actually recommend that. What do others think? Cheers Simon On Mon, 1 Aug 2022 at 07:45, Joachim Breitner wrote:

...

Dear Committee,

Add implicit import proposal has been submitted by Tristan de Cacqueray

This is an interesting one: At first glance it looks quite un- haskellish, but it’s hard to poing out what’s, if anything, is wrong with it. I expect that the discussion will revolve not so much about technical issues, but more about best practices and our vision for Haskell’s look and feel.

https://github.com/ghc-proposals/ghc-proposals/pull/500

https://github.com/TristanCacqueray/ghc-proposals/blob/implicit-import/propo...

I originally assigned this to Baldur in May, but we haven't heard from you. To be considerate of the proposal author’s motivation, I’d like to re-assign this to Simon Marlow.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

29 Aug 29 Aug

11:19 a.m.

New subject: Please review #500: Add implicit import proposal, New Shepherd: Simon M.

Hi Simon, thanks for picking this up. I am similarly torn. Everytime I have to add and then remove Debug.Trace from my import list I am annoyed. And especially for quick scripts etc. having less red tape to go through seems to be an improvement. So I see the benefit. If I’d be creating a programming language afresh, I might be inclined to allow that – a qualified identifier is already quite explicit, after all! (I admit that I still don’t use the latest tooling available, maybe someone using LSP for all their Haskell uses might have a different.) On the other hand, this is not a fresh programming language, we have lived okish without this so far, and in particular the behavior with regard to instances might be sufficient reasons to reject this – although not without some regret. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Eric Seidel

12:59 p.m.

New subject: Please review #500: Add implicit import proposal, New Shepherd: Simon M.

If the main benefit we expect from this feature is improved development productivity (from not having to jump around to insert temporary imports), I can think of two ways to restrict the feature to keep most of the benefit without dealing with tricky questions like instance imports. 1a. Never import instances via an implicit import. This limits the usefulness somewhat if you're trying to use an overloaded method, because you might depend on the instances that would come alongside the method. But, it's an easy rule to remember, and our goal is to improve dev productivity, not provide a production-grade solution. 1b. Always import instances via an implicit import. Same argument as above, but perhaps more friendly to productivity. 2. Always warn about implicit imports so they mostly stay out of production builds. On Mon, Aug 29, 2022, at 11:19, Joachim Breitner wrote:

...

Hi Simon,

thanks for picking this up.

I am similarly torn.

Everytime I have to add and then remove Debug.Trace from my import list I am annoyed. And especially for quick scripts etc. having less red tape to go through seems to be an improvement. So I see the benefit. If I’d be creating a programming language afresh, I might be inclined to allow that – a qualified identifier is already quite explicit, after all! (I admit that I still don’t use the latest tooling available, maybe someone using LSP for all their Haskell uses might have a different.)

On the other hand, this is not a fresh programming language, we have lived okish without this so far, and in particular the behavior with regard to instances might be sufficient reasons to reject this – although not without some regret.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Iavor Diatchki

31 Aug 31 Aug

1:23 a.m.

New subject: Please review #500: Add implicit import proposal, New Shepherd: Simon M.

Hello, I am not on the committee anymore but I like reading the discussions while having a coffee, so I thought I'd chime in with my 2c: using an `import` declaration, you get to introduce a shorter qualifier (the `as` clause), which for me as a programmer is essential---I don't remember the last time I used a `qualified` import without an `as`, which is what you'd get with this proposal. -Iavor On Mon, Aug 29, 2022, 20:00 Eric Seidel wrote:

...

If the main benefit we expect from this feature is improved development productivity (from not having to jump around to insert temporary imports), I can think of two ways to restrict the feature to keep most of the benefit without dealing with tricky questions like instance imports.

1a. Never import instances via an implicit import. This limits the usefulness somewhat if you're trying to use an overloaded method, because you might depend on the instances that would come alongside the method. But, it's an easy rule to remember, and our goal is to improve dev productivity, not provide a production-grade solution.

1b. Always import instances via an implicit import. Same argument as above, but perhaps more friendly to productivity.

2. Always warn about implicit imports so they mostly stay out of production builds.

On Mon, Aug 29, 2022, at 11:19, Joachim Breitner wrote:

...
Hi Simon,

thanks for picking this up.

I am similarly torn.

Everytime I have to add and then remove Debug.Trace from my import list I am annoyed. And especially for quick scripts etc. having less red tape to go through seems to be an improvement. So I see the benefit. If I’d be creating a programming language afresh, I might be inclined to allow that – a qualified identifier is already quite explicit, after all! (I admit that I still don’t use the latest tooling available, maybe someone using LSP for all their Haskell uses might have a different.)

On the other hand, this is not a fresh programming language, we have lived okish without this so far, and in particular the behavior with regard to instances might be sufficient reasons to reject this – although not without some regret.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Marlow

3:07 p.m.

New subject: Please review #500: Add implicit import proposal, New Shepherd: Simon M.

I just checked the proposal and in fact, Eric's 1a option below is what is being proposed. That is, implicit imports don't bring any new instances into scope. For me I don't think that actually simplifies things though. Because now, we have a difference in semantics between using an implicit import and an explicit import, and a weird corner case that will surprise people. I'm somewhat attracted by option 2, warning about implicit imports. If this is supposed to be a convenience feature during development, I could see that being useful. In a similar vein, I suggested on github that implicit imports could work only for modules outside the current package, which avoids a lot of the implementation complexity because we don't have to extract implicit imports to perform dependency analysis. As a language feature I think that's a terrible design, but as a productivity tool during development it makes some sense - rather like the intention behind the existing hacky feature in GHCi that the whole proposal is inspired by. But do we actually want that kind of feature? I'm still not sure really. Cheers Simon On Mon, 29 Aug 2022 at 18:00, Eric Seidel wrote:

...

If the main benefit we expect from this feature is improved development productivity (from not having to jump around to insert temporary imports), I can think of two ways to restrict the feature to keep most of the benefit without dealing with tricky questions like instance imports.

1a. Never import instances via an implicit import. This limits the usefulness somewhat if you're trying to use an overloaded method, because you might depend on the instances that would come alongside the method. But, it's an easy rule to remember, and our goal is to improve dev productivity, not provide a production-grade solution.

1b. Always import instances via an implicit import. Same argument as above, but perhaps more friendly to productivity.

2. Always warn about implicit imports so they mostly stay out of production builds.

On Mon, Aug 29, 2022, at 11:19, Joachim Breitner wrote:

...
Hi Simon,

thanks for picking this up.

I am similarly torn.

Everytime I have to add and then remove Debug.Trace from my import list I am annoyed. And especially for quick scripts etc. having less red tape to go through seems to be an improvement. So I see the benefit. If I’d be creating a programming language afresh, I might be inclined to allow that – a qualified identifier is already quite explicit, after all! (I admit that I still don’t use the latest tooling available, maybe someone using LSP for all their Haskell uses might have a different.)

On the other hand, this is not a fresh programming language, we have lived okish without this so far, and in particular the behavior with regard to instances might be sufficient reasons to reject this – although not without some regret.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Marlow

3:13 p.m.

New subject: Please review #500: Add implicit import proposal, New Shepherd: Simon M.

Anyway, for what it's worth the proposer has asked to mark the proposal dormant until the compile-time performance issues can be resolved. Thanks everyone for the discussion, we can revisit this if/when the proposal wakes up again. Cheers Simon On Wed, 31 Aug 2022 at 20:07, Simon Marlow wrote:

...

I just checked the proposal and in fact, Eric's 1a option below is what is being proposed. That is, implicit imports don't bring any new instances into scope.

For me I don't think that actually simplifies things though. Because now, we have a difference in semantics between using an implicit import and an explicit import, and a weird corner case that will surprise people.

I'm somewhat attracted by option 2, warning about implicit imports. If this is supposed to be a convenience feature during development, I could see that being useful. In a similar vein, I suggested on github that implicit imports could work only for modules outside the current package, which avoids a lot of the implementation complexity because we don't have to extract implicit imports to perform dependency analysis. As a language feature I think that's a terrible design, but as a productivity tool during development it makes some sense - rather like the intention behind the existing hacky feature in GHCi that the whole proposal is inspired by. But do we actually want that kind of feature? I'm still not sure really.

Cheers Simon

On Mon, 29 Aug 2022 at 18:00, Eric Seidel wrote:

...
If the main benefit we expect from this feature is improved development productivity (from not having to jump around to insert temporary imports), I can think of two ways to restrict the feature to keep most of the benefit without dealing with tricky questions like instance imports.

1a. Never import instances via an implicit import. This limits the usefulness somewhat if you're trying to use an overloaded method, because you might depend on the instances that would come alongside the method. But, it's an easy rule to remember, and our goal is to improve dev productivity, not provide a production-grade solution.

1b. Always import instances via an implicit import. Same argument as above, but perhaps more friendly to productivity.

2. Always warn about implicit imports so they mostly stay out of production builds.

On Mon, Aug 29, 2022, at 11:19, Joachim Breitner wrote:

...
Hi Simon,

thanks for picking this up.

I am similarly torn.

Everytime I have to add and then remove Debug.Trace from my import list I am annoyed. And especially for quick scripts etc. having less red tape to go through seems to be an improvement. So I see the benefit. If I’d be creating a programming language afresh, I might be inclined to allow that – a qualified identifier is already quite explicit, after all! (I admit that I still don’t use the latest tooling available, maybe someone using LSP for all their Haskell uses might have a different.)

On the other hand, this is not a fresh programming language, we have lived okish without this so far, and in particular the behavior with regard to instances might be sufficient reasons to reject this – although not without some regret.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Richard Eisenberg

6 p.m.

New subject: Please review #500: Add implicit import proposal, New Shepherd: Simon M.

Just because it's paged in now: I, too, am on the fence. But I want to vote against warning at every implicit import, because I often develop with -Werror on. If the whole point of this is to enable Debug.Trace.trace, then I've lost the benefit. I'm attracted by the idea of leaning more heavily on external tooling. For example, we can imagine a command-line option that specifies an `import` statement. Tooling can generate the right such options. That would seem to be better than making this a language feature, because an external tool is in a better position to know e.g. how to disambiguate if there are multiple X.Y modules available from different packages. Richard

...

On Aug 31, 2022, at 3:13 PM, Simon Marlow wrote:

Anyway, for what it's worth the proposer has asked to mark the proposal dormant until the compile-time performance issues can be resolved.

Thanks everyone for the discussion, we can revisit this if/when the proposal wakes up again.

Cheers Simon

On Wed, 31 Aug 2022 at 20:07, Simon Marlow mailto:marlowsd@gmail.com> wrote: I just checked the proposal and in fact, Eric's 1a option below is what is being proposed. That is, implicit imports don't bring any new instances into scope.

For me I don't think that actually simplifies things though. Because now, we have a difference in semantics between using an implicit import and an explicit import, and a weird corner case that will surprise people.

I'm somewhat attracted by option 2, warning about implicit imports. If this is supposed to be a convenience feature during development, I could see that being useful. In a similar vein, I suggested on github that implicit imports could work only for modules outside the current package, which avoids a lot of the implementation complexity because we don't have to extract implicit imports to perform dependency analysis. As a language feature I think that's a terrible design, but as a productivity tool during development it makes some sense - rather like the intention behind the existing hacky feature in GHCi that the whole proposal is inspired by. But do we actually want that kind of feature? I'm still not sure really.

Cheers Simon

On Mon, 29 Aug 2022 at 18:00, Eric Seidel mailto:eric@seidel.io> wrote: If the main benefit we expect from this feature is improved development productivity (from not having to jump around to insert temporary imports), I can think of two ways to restrict the feature to keep most of the benefit without dealing with tricky questions like instance imports.

1a. Never import instances via an implicit import. This limits the usefulness somewhat if you're trying to use an overloaded method, because you might depend on the instances that would come alongside the method. But, it's an easy rule to remember, and our goal is to improve dev productivity, not provide a production-grade solution.

1b. Always import instances via an implicit import. Same argument as above, but perhaps more friendly to productivity.

2. Always warn about implicit imports so they mostly stay out of production builds.

On Mon, Aug 29, 2022, at 11:19, Joachim Breitner wrote:

...
Hi Simon,

thanks for picking this up.

I am similarly torn.

Everytime I have to add and then remove Debug.Trace from my import list I am annoyed. And especially for quick scripts etc. having less red tape to go through seems to be an improvement. So I see the benefit. If I’d be creating a programming language afresh, I might be inclined to allow that – a qualified identifier is already quite explicit, after all! (I admit that I still don’t use the latest tooling available, maybe someone using LSP for all their Haskell uses might have a different.)

On the other hand, this is not a fresh programming language, we have lived okish without this so far, and in particular the behavior with regard to instances might be sufficient reasons to reject this – although not without some regret.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Spiwack, Arnaud

5 Sep 5 Sep

5:47 a.m.

New subject: Please review #500: Add implicit import proposal, New Shepherd: Simon M.

On my end, I think that implementing this proposal with a warning, à la Eric's (2) is an absolutely decent option. That being said, it's not a tremendously useful feature either. It's not the odd `Debug.Trace` that costs much time. Imports in Haskell are costly because they are too fine-grained. Therefore import statement lists are really long, and you will spend a lot of time managing them (it's in particular a non-trivial impediment to inter-module refactorings). This proposal doesn't address this sort of situation. So the value of this proposal is probably very small, if the cost of implementing this proposal is non-trivial, then it's probably not worth going for it. On Thu, Sep 1, 2022 at 12:00 AM Richard Eisenberg wrote:

...

Just because it's paged in now: I, too, am on the fence. But I want to vote against warning at every implicit import, because I often develop with -Werror on. If the whole point of this is to enable Debug.Trace.trace, then I've lost the benefit.

I'm attracted by the idea of leaning more heavily on external tooling. For example, we can imagine a command-line option that specifies an `import` statement. Tooling can generate the right such options. That would seem to be better than making this a language feature, because an external tool is in a better position to know e.g. how to disambiguate if there are multiple X.Y modules available from different packages.

Richard

On Aug 31, 2022, at 3:13 PM, Simon Marlow wrote:

Anyway, for what it's worth the proposer has asked to mark the proposal dormant until the compile-time performance issues can be resolved.

Thanks everyone for the discussion, we can revisit this if/when the proposal wakes up again.

Cheers Simon

On Wed, 31 Aug 2022 at 20:07, Simon Marlow wrote:

...
I just checked the proposal and in fact, Eric's 1a option below is what is being proposed. That is, implicit imports don't bring any new instances into scope.

For me I don't think that actually simplifies things though. Because now, we have a difference in semantics between using an implicit import and an explicit import, and a weird corner case that will surprise people.

I'm somewhat attracted by option 2, warning about implicit imports. If this is supposed to be a convenience feature during development, I could see that being useful. In a similar vein, I suggested on github that implicit imports could work only for modules outside the current package, which avoids a lot of the implementation complexity because we don't have to extract implicit imports to perform dependency analysis. As a language feature I think that's a terrible design, but as a productivity tool during development it makes some sense - rather like the intention behind the existing hacky feature in GHCi that the whole proposal is inspired by. But do we actually want that kind of feature? I'm still not sure really.

Cheers Simon

On Mon, 29 Aug 2022 at 18:00, Eric Seidel wrote:

...
If the main benefit we expect from this feature is improved development productivity (from not having to jump around to insert temporary imports), I can think of two ways to restrict the feature to keep most of the benefit without dealing with tricky questions like instance imports.

1a. Never import instances via an implicit import. This limits the usefulness somewhat if you're trying to use an overloaded method, because you might depend on the instances that would come alongside the method. But, it's an easy rule to remember, and our goal is to improve dev productivity, not provide a production-grade solution.

1b. Always import instances via an implicit import. Same argument as above, but perhaps more friendly to productivity.

2. Always warn about implicit imports so they mostly stay out of production builds.

On Mon, Aug 29, 2022, at 11:19, Joachim Breitner wrote:

...
Hi Simon,

thanks for picking this up.

I am similarly torn.

Everytime I have to add and then remove Debug.Trace from my import list I am annoyed. And especially for quick scripts etc. having less red tape to go through seems to be an improvement. So I see the benefit. If I’d be creating a programming language afresh, I might be inclined to allow that – a qualified identifier is already quite explicit, after all! (I admit that I still don’t use the latest tooling available, maybe someone using LSP for all their Haskell uses might have a different.)

On the other hand, this is not a fresh programming language, we have lived okish without this so far, and in particular the behavior with regard to instances might be sufficient reasons to reject this – although not without some regret.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

989

Age (days ago)

1112

Last active (days ago)

List overview

Download

9 comments

6 participants

participants (6)

Eric Seidel
Iavor Diatchki
Joachim Breitner
Richard Eisenberg
Simon Marlow
Spiwack, Arnaud

Please review #500: Add implicit import proposal, Shepherd: Baldur

tags

participants (6)