[ghc-steering-committee] Please review #500: Add implicit import proposal, New Shepherd: Simon M.

[Spiwack, Arnaud]

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 <lists at richarde.dev>
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 <marlowsd at gmail.com> 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 <marlowsd at 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 <eric at 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 at joachim-breitner.de
>>> >   http://www.joachim-breitner.de/
>>> >
>>> > _______________________________________________
>>> > ghc-steering-committee mailing list
>>> > ghc-steering-committee at haskell.org
>>> >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220905/85b863fa/attachment.html>