The desired editor features are written in the haskell spec? I'm talking about the language in an editor/IDE agnostic way. If the IDE/editor is hiding it for you, it is because the language failed to be good enough to be "out of the way". So, I guess this is a +1. 2014-04-22 15:04 GMT-03:00 Ben Foppa :

Why not have an editor that collapses them?

On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri wrote:

...

When reading code, I find it quite distracting to have to get past the import list to reach the actual module code, as the import list can be (and often is) quite big.

So, why not issue import statements at the bottom of a module file?

Likewise, we can use "where" statements to define names used in a function after using them, so they don't distract the reader.

I'm against imports at the middle of the file. But I guess being able to issue them at the end of the module could make sense if you want to get the reader straight to the code.

A language pragma could be used to select between top imports or bottom imports (can't use both).

What do you think?

Example:

""" {-# LANGUAGE LateImports #-} module Foo where

bar :: String bar = "quux"

baz :: Fiz baz = mkFiz

import Fiz (Fiz, mkFiz) """

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

In that case, there is no language that is "good enough", because liking code folding is language agnostic. Personally, I like imports at the top, as they let me know what functions I can expect to find in the module. At least, if used properly. Which shows the real problem with this suggestion: some modules will have imports at the top and some at the bottom, so if you're looking at the middle of the module and want to check on them, you've got to guess where they are. Frankly, if the goal is to get them out of the way, I'd rather see "local imports" in a where or in clause, so you can add them to the expression that needs them. But that has little enough utility that I'd rather not do it, either. Hmm, maybe only in the "import Module (thing ...)" form? Nah. On Tue, Apr 22, 2014 at 1:18 PM, Thiago Negri wrote:

The desired editor features are written in the haskell spec? I'm talking about the language in an editor/IDE agnostic way. If the IDE/editor is hiding it for you, it is because the language failed to be good enough to be "out of the way". So, I guess this is a +1.

2014-04-22 15:04 GMT-03:00 Ben Foppa :

...

Why not have an editor that collapses them?

On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri wrote:

...

When reading code, I find it quite distracting to have to get past the import list to reach the actual module code, as the import list can be (and often is) quite big.

So, why not issue import statements at the bottom of a module file?

Likewise, we can use "where" statements to define names used in a function after using them, so they don't distract the reader.

I'm against imports at the middle of the file. But I guess being able to issue them at the end of the module could make sense if you want to get the reader straight to the code.

A language pragma could be used to select between top imports or bottom imports (can't use both).

What do you think?

Example:

""" {-# LANGUAGE LateImports #-} module Foo where

bar :: String bar = "quux"

baz :: Fiz baz = mkFiz

import Fiz (Fiz, mkFiz) """

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

How did this work out in other languages which have imports at the bottom? - Clark On Tue, Apr 22, 2014 at 3:07 PM, Thiago Negri wrote:

Just to get things clear... I'm not saying that folding is a bad thing. But it is not a valid reason to invalidate a "import at bottom" feature.

It's like saying that if you shouldn't care if you have a broken leg, just grab a crutch and you are good to go: "don't bother going to a physiotherapist."

The code analysis situations are valid reasons, but I still prefer the language to be easier to man than to machine. Adding them at the bottom would incur an absurd overhead? You don't need to scan the file looking for imports, you can scan bottom-up the same way you would scan top-down. Or would you need a "do-nothing-scan" to find the end of file? (Sorry, I lack knowledge in file system implementations.)

I browse a lot of code on github, and I don't find a way to fold import statements on the website.

2014-04-22 15:48 GMT-03:00 Mike Meyer :

In that case, there is no language that is "good enough", because liking

...

code folding is language agnostic.

Personally, I like imports at the top, as they let me know what functions I can expect to find in the module. At least, if used properly. Which shows the real problem with this suggestion: some modules will have imports at the top and some at the bottom, so if you're looking at the middle of the module and want to check on them, you've got to guess where they are.

Frankly, if the goal is to get them out of the way, I'd rather see "local imports" in a where or in clause, so you can add them to the expression that needs them. But that has little enough utility that I'd rather not do it, either. Hmm, maybe only in the "import Module (thing ...)" form? Nah.

On Tue, Apr 22, 2014 at 1:18 PM, Thiago Negri wrote:

...

The desired editor features are written in the haskell spec? I'm talking about the language in an editor/IDE agnostic way. If the IDE/editor is hiding it for you, it is because the language failed to be good enough to be "out of the way". So, I guess this is a +1.

2014-04-22 15:04 GMT-03:00 Ben Foppa :

...

Why not have an editor that collapses them?

On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri wrote:

...

When reading code, I find it quite distracting to have to get past the import list to reach the actual module code, as the import list can be (and often is) quite big.

So, why not issue import statements at the bottom of a module file?

Likewise, we can use "where" statements to define names used in a function after using them, so they don't distract the reader.

I'm against imports at the middle of the file. But I guess being able to issue them at the end of the module could make sense if you want to get the reader straight to the code.

A language pragma could be used to select between top imports or bottom imports (can't use both).

What do you think?

Example:

""" {-# LANGUAGE LateImports #-} module Foo where

bar :: String bar = "quux"

baz :: Fiz baz = mkFiz

import Fiz (Fiz, mkFiz) """

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907

On 23 April 2014 04:28, Niklas Haas wrote:

On Tue, 22 Apr 2014 14:59:44 -0300, Thiago Negri wrote:

...

When reading code, I find it quite distracting to have to get past the import list to reach the actual module code, as the import list can be (and often is) quite big.

So, why not issue import statements at the bottom of a module file?

Likewise, we can use "where" statements to define names used in a function after using them, so they don't distract the reader.

I'm against imports at the middle of the file. But I guess being able to issue them at the end of the module could make sense if you want to get the reader straight to the code.

A language pragma could be used to select between top imports or bottom imports (can't use both).

What do you think?

Example:

""" {-# LANGUAGE LateImports #-} module Foo where

bar :: String bar = "quux"

baz :: Fiz baz = mkFiz

import Fiz (Fiz, mkFiz) """

A practical reason is that this lets you process modules dependency graphs without ever analyzing the structure past the import list.

Also so when you're reading the code you have an idea up-front of what kind of external modules it might be using; otherwise - especially if the names are generic (e.g. "Parser") or using some form of overloaded extension (e.g. OverloadedStrings) - you might not be able to tell as easily the behaviour of the code. After all, two different parser libraries might behave differently (how they deal with backtracking is usually a big difference), and if you see someone using OverloadedStrings with ByteStrings then you know to be more careful about the code if using characters not expressable in a single byte. Whilst I doubt this is a common use-case in practice, it's also possible someone might want to add some code to a file using a shell script: if the imports are at the top you can just append it; if the imports are at the bottom you have to be more careful. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

I think it's a great idea. Go for it. "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. 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. 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. 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. 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. Alexander On Wed, Apr 23, 2014 at 12:37 AM, Thiago Negri wrote:

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.

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. Em 22/04/2014 19:09, "Ivan Lazar Miljenovic" escreveu:

On 23 April 2014 04:28, Niklas Haas wrote:

...

...

On Tue, 22 Apr 2014 14:59:44 -0300, Thiago Negri wrote:

...

When reading code, I find it quite distracting to have to get past the import list to reach the actual module code, as the import list can be (and often is) quite big.

So, why not issue import statements at the bottom of a module file?

Likewise, we can use "where" statements to define names used in a function after using them, so they don't distract the reader.

I'm against imports at the middle of the file. But I guess being able to issue them at the end of the module could make sense if you want to get the reader straight to the code.

A language pragma could be used to select between top imports or bottom imports (can't use both).

What do you think?

Example:

""" {-# LANGUAGE LateImports #-} module Foo where

bar :: String bar = "quux"

baz :: Fiz baz = mkFiz

import Fiz (Fiz, mkFiz) """

A practical reason is that this lets you process modules dependency graphs without ever analyzing the structure past the import list.

Also so when you're reading the code you have an idea up-front of what kind of external modules it might be using; otherwise - especially if the names are generic (e.g. "Parser") or using some form of overloaded extension (e.g. OverloadedStrings) - you might not be able to tell as easily the behaviour of the code.

After all, two different parser libraries might behave differently (how they deal with backtracking is usually a big difference), and if you see someone using OverloadedStrings with ByteStrings then you know to be more careful about the code if using characters not expressable in a single byte.

Whilst I doubt this is a common use-case in practice, it's also possible someone might want to add some code to a file using a shell script: if the imports are at the top you can just append it; if the imports are at the bottom you have to be more careful.

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Someone asked "what about other languages that use bottom imports?" It's actually a pretty rare language feature. Off-hand, I've used more languages where assignment is (or can be) written "expr -> var" than languages with bottom imports. If you don't want to be distracted by imports, you could use your favoured editor's chroma-coding features to colour them grey, so that your eye naturally skips to the rest of the code. One major problem is that as long as (a) you need to read other people's code as well as your own and (b) the language allows top imports, allowing bottom imports will FAIL TO SOLVE the problem it was invented for: you will *still* have to deal with top imports when reading other people's code. To be honest, folding the imports seems to me like the perfect solution: no language change (given that there _are_ other compilers than GHC, this seems like a Good Thing), a click away when you do want to see what's there but just one (-)imports line when you don't. I for one *prefer* seeing the imports at the top; I would find imports at the bottom very unpleasant to work with. Perhaps that's because I'm used to top imports everywhere else.

On 20 May 2014 20:41, Jochen Keil wrote:

...

The first technical problem I see is that a compiler can't easily generate a dependency graph without first parsing the whole module.

Pardon my ignorance, but couldn't you just ignore every line that doesn't start with 'import'?

I see two problems: 1) Standard Haskell has semi-colons for declaration separation, not just lines. So you could write x = do { putStrLn "Quoth I; sup?"; print "X" }; import Data.List; y = "oopie" You would have to parse this (to some depth) to figure out where x starts and the Data.List import begins. 2) With Template-Haskell enabled, you'd need to run the TH to ignore quasi-quotes that just happen to contain "import X", and if imports could appear anywhere, then TH would probably allow it, too, which would mean you'd have to run the TH in a module to find out what else it imports. With the restrictions imposed on imports being directly after module headers right now, a compiler can trivially scan through everything before even starting to parse (and quickly point out import cycles, or missing modules).