<div dir="ltr"><div>Apologies for the delay here, holidays and then a large backlog...</div><div><br></div><div>As a reminder, this proposal would let you use qualified names like <span style="font-family:monospace">Data.Trace.trace <span style="font-family:arial,sans-serif">without adding an explicit import.</span><br></span></div><div><span style="font-family:monospace"><br></span></div><div>I've reviewed the whole comment section of the proposal, but I'm finding it difficult to arrive at a clear recommendation. Some points:<br></div><div><ul><li>There's a certain amount of convenience enabled by the extension, for sure. And other languages (OCaml, Rust) have a similar feature.</li></ul><div>But<br></div><ul><li>There are compile-time performance implications that are as-yet unmeasured. I've asked for more data on this in the github thread.</li><li>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)</li><li>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.<br></li></ul><div>I'm personally leaning towards rejection, but I don't feel strongly enough to actually recommend that. What do others think?</div><div><br></div><div>Cheers</div><div>Simon<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 1 Aug 2022 at 07:45, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</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">Dear Committee,<br>
<br>
Add implicit import proposal<br>
has been submitted by Tristan de Cacqueray<br>
<br>
This is an interesting one: At first glance it looks quite un-<br>
haskellish, but it’s hard to poing out what’s, if anything, is wrong<br>
with it. I expect that the discussion will revolve not so much about<br>
technical issues, but more about best practices and our vision for<br>
Haskell’s look and feel.<br>
<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/500" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/500</a><br>
<a href="https://github.com/TristanCacqueray/ghc-proposals/blob/implicit-import/proposals/0000-implicit-import.rst" rel="noreferrer" target="_blank">https://github.com/TristanCacqueray/ghc-proposals/blob/implicit-import/proposals/0000-implicit-import.rst</a><br>
<br>
I originally assigned this to Baldur in May, but we haven't heard from<br>
you. To be considerate of the proposal author’s motivation, I’d like to<br>
re-assign this to Simon Marlow.<br>
<br>
Please guide us to a conclusion as outlined in <br>
<a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br>
<br>
Thanks,<br>
Joachim<br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="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" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>