Packages and modules

[Ketil Malde]

"Brian Hulley" <brianh at metamilk.com> writes:

> because if the suggested syntax is used, import directives come in two
> flavours: ones that use "from" to import from a different package and
> ones that don't use "from" and therefore must refer to the current
> package.

What is the "current package"?  My impression was that "from" would
only be needed when there was ambiguity.  (And if I wanted to type
myself to death, I'd be using Java :-)  If you *have* to specify
package, this makes things a lot less flexible (e.g., moving a module
from one package to another will break code)

Would 'base' be the current package in most cases?  That would
encourage cramming even more stuff into base¹, and I suspect the
overloaded 'base' is half the reason we're discussing all this extra
syntactical baggage.  (E.g. experimenting with a newer version of
Don's FPS, I basically need to replace 'base'.  With the features being
discussed, I could get by rewriting the import statements in all my
fps-using code, which would be an improvement.  It'd be much safer and
better to have a compiler option, of course, but I guess that will
only work for complete packages.)

Anyway (and like you say) I think the workaround using qualification
or hiding is more than sufficient, I consider recycling names from
imported modules for local variables questionable as best, and would
rather it wasn't encouraged. 

> 3) Syntax:
> I liked Ian Lynagh's suggestion of using "from" to start either a
> single import directive or a block of import directives
> http://www.haskell.org//pipermail/haskell-cafe/2006-June/016338.html
> eg (modified to use quotes):

>    from "base"
>            import Predude hiding(length)
>            import Control.Exception
>            import qualified Data.List as List

Would this make 'from' a reserved word?  I think this is only useful
if you require the module to be declared, and thus not worth an extra
keyword (and code breakage) if non-ambigous modules can still be
imported. 

Anyway, I'd just like to say that I'm really happy about the way GHC
and Cabal currently works - 'ghc --make' takes care of package
imports, and Cabal is simple enough that most of my code gets
Cabalized these days.

-k

¹ What *is* the advantage of stuffing everything and the kitchen sink
into base, btw?
-- 
If I haven't seen further, it is by standing in the footprints of giants