I don't see the benefit of allowing imports anywhere at top-level. http://hackage.haskell.org/trac/haskell-prime/wiki/AllowImportAnywhere As with declarations I expect that imported identifiers are visible everywhere in a module. Thus the search for an imported identifier becomes even more complicated as it is today (due to anonymously imported identifiers and re-exported modules). Sometimes I missed a feature from the Modula-2 derivative named "Cluster", namely local imports of modules. Locally imported identifiers would be invisible to other functions. However I don't think that it is so important to be worth the trouble of implementing it.
Hello Henning, Sunday, October 22, 2006, 5:48:11 PM, you wrote:
I don't see the benefit of allowing imports anywhere at top-level.
it is useful to move together imports and related code. say: #if HUGS import Hugs.Base addInt = hugsAddInt #elseif GHC import GHC.Base addInt = ghcAddInt #endif currently we are forced to make separate sections for import and use: #if HUGS import Hugs.Base #elseif GHC import GHC.Base #endif #if HUGS addInt = hugsAddInt #elseif GHC addInt = ghcAddInt #endif just another example: -- higher-level stuff: openFile = ... -- medium-level-stuff createFD = .. -- low-level stuff import System,FD _create = ... System.FD.create (i don't propose subj. i just know pros and contras for it) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Sun, 22 Oct 2006, Bulat Ziganshin wrote:
Hello Henning,
Sunday, October 22, 2006, 5:48:11 PM, you wrote:
I don't see the benefit of allowing imports anywhere at top-level.
it is useful to move together imports and related code. say:
#if HUGS import Hugs.Base addInt = hugsAddInt #elseif GHC import GHC.Base addInt = ghcAddInt #endif
currently we are forced to make separate sections for import and use:
#if HUGS import Hugs.Base #elseif GHC import GHC.Base #endif
#if HUGS addInt = hugsAddInt #elseif GHC addInt = ghcAddInt #endif
We just need a system for plugging together system-dependent modules, that's all. We do not need preprocessor hacks for this issue: http://www.haskell.org/pipermail/haskell-cafe/2006-August/017503.html
Henning Thielemann
#if HUGS import Hugs.Base #elseif GHC import GHC.Base #endif
We just need a system for plugging together system-dependent modules, that's all. We do not need preprocessor hacks for this issue: http://www.haskell.org/pipermail/haskell-cafe/2006-August/017503.html
But in general, I often find I want to use CPP both to modify imports and provide function definitions. E.g. to provide sensible error messages for some Prelude functions (read, head, fromJust, etc), I have an include file that imports Prelude hiding the original definitions, and replace them with macros making use of CPP's __LINE__ and __FILE__. For some of the support functionality, I'm forced to write macros instead of functions, since I'd otherwise need to clutter all my modules with multiple #include statements. This tends to arise relatively often when I use #include -- if it is simple to implement, could perhaps this (mixing of imports and definitions) be allowed when -cpp is specified? -k -- If I haven't seen further, it is by standing in the footprints of giants
On 10/22/06, Bulat Ziganshin
Hello Henning,
Sunday, October 22, 2006, 5:48:11 PM, you wrote:
I don't see the benefit of allowing imports anywhere at top-level.
it is useful to move together imports and related code. say:
#if HUGS import Hugs.Base addInt = hugsAddInt #elseif GHC import GHC.Base addInt = ghcAddInt #endif
If imports were allowed everywhere, then would exports be allowed everywhere too, for the same reasons? Regards, Brian
participants (4)
-
Brian Smith -
Bulat Ziganshin -
Henning Thielemann -
Ketil Malde