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

[Simon Marlow]

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/c521f2ee/attachment.html>