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

[Simon Marlow]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220831/cc2042ce/attachment.html>