Imports at bottom, why not?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Imports at bottom, why not?

Thiago Negri
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Ben Foppa
Why not have an editor that collapses them?


On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Thiago Negri
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 <[hidden email]>:
Why not have an editor that collapses them?


On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Niklas Haas
In reply to this post by Thiago Negri
On Tue, 22 Apr 2014 14:59:44 -0300, Thiago Negri <[hidden email]> 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.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Magnus Therning
In reply to this post by Thiago Negri
On Tue, Apr 22, 2014 at 03:18:44PM -0300, 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.

Yay for top posting!

Well, collapsing (or folding) is a language agnostic way of hiding
away anything you like.  Do consider that what you want to hide
changes with the task at hand.

/M

> 2014-04-22 15:04 GMT-03:00 Ben Foppa <[hidden email]>:
>
> > Why not have an editor that collapses them?
> >
> >
> > On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri <[hidden email]> 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
> >> [hidden email]
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>
> >>
> >

> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe


--
Magnus Therning                      OpenPGP: 0xAB4DFBA4
email: [hidden email]   jabber: [hidden email]
twitter: magthe               http://therning.org/magnus

The results point out the fragility of programmer expertise: advanced
programmers have strong expectations about what programs should look like,
and when those expectations are violated--in seemingly innocuous
ways--their performance drops drastically.
     -- Elliot Soloway and Kate Ehrlich

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Dominique Devriese-2
In reply to this post by Thiago Negri
FWIW, a while ago I talked to one of the guys working on the official
Eclipse Scala plugin. He said that Scala's policy of allowing imports
pretty much everywhere made it quite hard to build an IDE that's
responsive on large codebases. It's not quite the same, because Scala
allows much more than just imports at the bottom, but still...

Regards
Dominique

2014-04-22 19:59 GMT+02:00 Thiago Negri <[hidden email]>:

> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Mike Meyer
In reply to this post by Thiago Negri
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 <[hidden email]> 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 <[hidden email]>:
Why not have an editor that collapses them?


On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Thiago Negri
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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
Why not have an editor that collapses them?


On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Clark Gaebel-2
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:
Why not have an editor that collapses them?


On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
Clark.

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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Ivan Lazar Miljenovic
In reply to this post by Niklas Haas
On 23 April 2014 04:28, Niklas Haas <[hidden email]> wrote:

> On Tue, 22 Apr 2014 14:59:44 -0300, Thiago Negri <[hidden email]> 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
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Thiago Negri

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" <[hidden email]> escreveu:
On 23 April 2014 04:28, Niklas Haas <[hidden email]> wrote:
> On Tue, 22 Apr 2014 14:59:44 -0300, Thiago Negri <[hidden email]> 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
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Alexander Kjeldaas

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 <[hidden email]> 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" <[hidden email]> escreveu:

On 23 April 2014 04:28, Niklas Haas <[hidden email]> wrote:
> On Tue, 22 Apr 2014 14:59:44 -0300, Thiago Negri <[hidden email]> 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
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Andrew Fleckenstein
IMHO, when you are unfamiliar with the codebase (like me), it's nice to see the imports first to give yourself a bearing point.


On Tue, Apr 22, 2014 at 7:33 PM, Alexander Kjeldaas <[hidden email]> wrote:

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 <[hidden email]> 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" <[hidden email]> escreveu:

On 23 April 2014 04:28, Niklas Haas <[hidden email]> wrote:
> On Tue, 22 Apr 2014 14:59:44 -0300, Thiago Negri <[hidden email]> 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
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Simon Hengel
In reply to this post by Thiago Negri
> So, why not issue import statements at the bottom of a module file?

Because then you have to deal with two ways of reading code (unless you
only intend to read code that you have written your self).

Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Richard A. O'Keefe
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.


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Christopher Done-2
In reply to this post by Thiago Negri
On 22 April 2014 19:59, Thiago Negri <[hidden email]> wrote:
> So, why not issue import statements at the bottom of a module file?

The first technical problem I see is that a compiler can't easily
generate a dependency graph without first parsing the whole module. In
contrast, current Haskell forbids anything but a module header, some
pragmas and an import list to start any module.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Imports at bottom, why not?

Christopher Done-2
On 20 May 2014 20:41, Jochen Keil <[hidden email]> 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).


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe