<div dir="ltr"><div dir="auto">Hello,<div dir="auto"><br></div><div>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.  <br></div></div><div><br></div><div>-Iavor<br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 29, 2022, 20:00 Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
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.<br>
<br>
1b. Always import instances via an implicit import. Same argument as above, but perhaps more friendly to productivity.<br>
<br>
2. Always warn about implicit imports so they mostly stay out of production builds.<br>
<br>
On Mon, Aug 29, 2022, at 11:19, Joachim Breitner wrote:<br>
> Hi Simon,<br>
><br>
> thanks for picking this up.<br>
><br>
> I am similarly torn.<br>
><br>
> Everytime I have to add and then remove Debug.Trace from my import list<br>
> I am annoyed. And especially for quick scripts etc. having less red<br>
> tape to go through seems to be an improvement. So I see the benefit. If<br>
> I’d be creating a programming language afresh, I might be inclined to<br>
> allow that – a qualified identifier is already quite explicit, after<br>
> all!<br>
> (I admit that I still don’t use the latest tooling available, maybe<br>
> someone using LSP for all their Haskell uses might have a different.)<br>
><br>
> On the other hand, this is not a fresh programming language, we have<br>
> lived okish without this so far, and in particular the behavior with<br>
> regard to instances might be sufficient reasons to reject this –<br>
> although not without some regret.<br>
><br>
><br>
> Cheers,<br>
> Joachim<br>
> -- <br>
> Joachim Breitner<br>
>   <a href="mailto:mail@joachim-breitner.de" rel="noreferrer" target="_blank">mail@joachim-breitner.de</a><br>
>   <a href="http://www.joachim-breitner.de/" rel="noreferrer noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
><br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" rel="noreferrer" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" rel="noreferrer" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>