<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">IMHO, when you are unfamiliar with the codebase (like me), it's nice to see the imports first to give yourself a bearing point.<br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 22, 2014 at 7:33 PM, Alexander Kjeldaas <span dir="ltr"><<a href="mailto:alexander.kjeldaas@gmail.com" target="_blank">alexander.kjeldaas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><br></div>I think it's a great idea.  Go for it.<br><br></div>"Real" haskell, similar to "real" java and C++ contains a long list of imports, much longer than what you typically have in toy examples.  This leads to IDEs needing to hide them, because when they start growing, they start being noisy.<br>


<br></div>Regarding the informational value in imports, I've written elisp support for both java and haskell where the imports are "guessed" based on compiler feedback/errors.  The result of this is that very simple heuristics (looking at other open buffers to see what they use for example) is able to guess the imports in 99% of the cases.<br>


<br>This means that the imports have little informational value.  If a simple program can write the missing code, it is unlikely that it contributes much to a reader's comprehension of the code.  I think, based on the success my auto-imports helper has for my code that the information value is inversely proportional to the number of files a reader has seen in the project.  Some imports correlate between projects and these mostly standardized imports have even less informational value.<br>


<br></div>I think the more "industrial" the code is, the more moving parts it juggles, the more imports will be used and the more readability is gained by putting them at the bottom.<br><br></div>Based on the redundancy in this information, maybe there are other ways to innovate around representing this information more succinct and useful across multiple files in projects.<span class="HOEnZb"><font color="#888888"><br>


<div><br><div><br></div><div>Alexander<br></div></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 23, 2014 at 12:37 AM, Thiago Negri <span dir="ltr"><<a href="mailto:evohunz@gmail.com" target="_blank">evohunz@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Appending code to a module via script is a valid use case, but then you just use top imports. This doesn't make a point towards forbidding bottom imports.</p>



<p dir="ltr">The point is: there are a number of reasons to do top imports and another number of reasons to do bottom imports. I think bottom imports could be very useful. Even literate Haskell could read better with bottom imports, in my opinion.</p>




<div class="gmail_quote">Em 22/04/2014 19:09, "Ivan Lazar Miljenovic" <<a href="mailto:ivan.miljenovic@gmail.com" target="_blank">ivan.miljenovic@gmail.com</a>> escreveu:<div><div><br type="attribution">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 23 April 2014 04:28, Niklas Haas <<a href="mailto:haskell@nand.wakku.to" target="_blank">haskell@nand.wakku.to</a>> wrote:<br>
> On Tue, 22 Apr 2014 14:59:44 -0300, Thiago Negri <<a href="mailto:evohunz@gmail.com" target="_blank">evohunz@gmail.com</a>> wrote:<br>
>> When reading code, I find it quite distracting to have to get past the<br>
>> import list to reach the actual module code, as the import list can be (and<br>
>> often is) quite big.<br>
>><br>
>> So, why not issue import statements at the bottom of a module file?<br>
>><br>
>> Likewise, we can use "where" statements to define names used in a function<br>
>> after using them, so they don't distract the reader.<br>
>><br>
>> I'm against imports at the middle of the file.<br>
>> But I guess being able to issue them at the end of the module could make<br>
>> sense if you want to get the reader straight to the code.<br>
>><br>
>> A language pragma could be used to select between top imports or bottom<br>
>> imports (can't use both).<br>
>><br>
>> What do you think?<br>
>><br>
>> Example:<br>
>><br>
>> """<br>
>> {-# LANGUAGE LateImports #-}<br>
>> module Foo where<br>
>><br>
>> bar :: String<br>
>> bar = "quux"<br>
>><br>
>> baz :: Fiz<br>
>> baz = mkFiz<br>
>><br>
>> import Fiz (Fiz, mkFiz)<br>
>> """<br>
><br>
> A practical reason is that this lets you process modules dependency<br>
> graphs without ever analyzing the structure past the import list.<br>
<br>
Also so when you're reading the code you have an idea up-front of what<br>
kind of external modules it might be using; otherwise - especially if<br>
the names are generic (e.g. "Parser") or using some form of overloaded<br>
extension (e.g. OverloadedStrings) - you might not be able to tell as<br>
easily the behaviour of the code.<br>
<br>
After all, two different parser libraries might behave differently<br>
(how they deal with backtracking is usually a big difference), and if<br>
you see someone using OverloadedStrings with ByteStrings then you know<br>
to be more careful about the code if using characters not expressable<br>
in a single byte.<br>
<br>
Whilst I doubt this is a common use-case in practice, it's also<br>
possible someone might want to add some code to a file using a shell<br>
script: if the imports are at the top you can just append it; if the<br>
imports are at the bottom you have to be more careful.<br>
<br>
--<br>
Ivan Lazar Miljenovic<br>
<a href="mailto:Ivan.Miljenovic@gmail.com" target="_blank">Ivan.Miljenovic@gmail.com</a><br>
<a href="http://IvanMiljenovic.wordpress.com" target="_blank">http://IvanMiljenovic.wordpress.com</a><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div></div></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>