[Haskell-cafe] Packages and modules

[Brian Hulley]

Marc Weber wrote:
> I'm not sure on which mail of this thread I should append MHO.
>
> What happens if two programmers "happen" to choose the same package
> name? (Prepend the location on the filesystem? ;-)
>
> If something like a package name is introduced I would prefer not
> separating package and module name with a "." because you might then
> even use the package name to point to a web address from where to load
> code (source/ binary/ byte code??) from.. Then creating something like
> Java applets would be more easy. We can't ignore this completely as
> the world (or important parts eg Windows) will try to bring more
> richness to internet applications/ the user.. They strive to
> integrate web applications so that you as user can't see if you're
> running a native or a
> downloaded application... If you use eg "," as separator you can use
> dots in the package name without hassle.

I think the package alias syntax would help here eg (non-existent url):

  package http://www.metamilk.com/packages/duma-1.0 as Duma

  import Duma/Text.Line  -- etc

I don't think the package name should ever be written directly into the 
import statement, because the package name needs to be able to use normal 
filename syntax but a component of a module identifier needs to conform to 
Haskell syntax because it could be used anywhere (*) eg

   let
         x = Duma/Text.Line.take 5 y

Also, to clarify my reasons for wanting to make the package part of the 
module id syntactically distinct (by using eg / instead of .), the entire 
namespace of hierarchical modules is supposed to be internal to each 
package, and therefore any id of the form A.B.C belongs to this internal 
namespace and therefore must refer to an internal module. All modules in 
external packages have ids of the form PackageAlias/ModulePath so when you 
read the source you (and the compiler) can tell at a glance whether you're 
referring to an internal or external module.
An extra advantage of making the package alias part syntactically visible is 
that we could make package directives optional in the common case where we 
want to just use the latest version of a package that has a globally agreed 
name eg

     import Fps/Data.ByteString  -- uses latest fps package

whereas if we just used import Fps.Data.ByteString the compiler would have 
no way to tell whether we're referring to an external package Fps or another 
module in our own package, and, imho, this would just simply be messy and 
inconsistent.

Also, although this requires changes to existing code, it should be possible 
to completely automate the change by using a simple conversion utility which 
knows about current packages, their prefixes, and what modules they contain 
(and therefore should be much less troublesome than the change from flat 
module namespace to hierarchical namespace).

(*) As an aside, it is a question to me whether identifiers in the body of a 
module should be allowed to be qualified with anything other than a module 
*alias*. Haskell98 just had flat modules, so the qualification was of the 
form A.val, whereas with the hierarchical extension you can use A.B.C.val 
etc. However does anyone actually ever use this rather than specifying an 
alias for A.B.C and using the alias to qualify val instead? This becomes a 
more urgent question if the lexical syntax for a module id needs to use 
another symbol such as /.

Regards, Brian.

-- 
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.

http://www.metamilk.com