Re: Fixing imports for and namespaces (was: Simon's H98 Notes)

[S. Alexander Jacobson]

On Mon, 19 Oct 1998, David Barton wrote:
> S. Alexander Jacobson writes:
>    And, as long as we are supporting more ADA-like import declarations,
>    I would like to renew my campaign for more ADA or Java like
>    module namespace (packages) (yes I know, this won't be in H98)
>    The existing module system is:
> 
>    * too shallow for larger scale application development (because it is too
>      easy for different developers to create modules with the same
>      name).
> 
> True, but easily fixable with the addition of a single library name.
> I have never found a reason to go much further than that, as long as
> the library name can be bound appropriately.

I am not sure what you mean by adding a library name.  My objection to the
current model is that, for example with hugs, each new library requires
you to add a path to your hugs path and hope that two different libraries
both don't share the same module name.

If module names were nested then you could reduce the liklihood of
namespace collision.  Java's requirement of putting the library
names inside the text of modules is annoying.  Use of the directory
hierarchy strikes me as simpler.
 
>    * a pain when you write a package with multiple modules and each module
>      has to import all the other modules in the package (except itself)
> 
> Disagree here; Haskell modules can re-export, meaning that it is easy
> to create "gather nodes" that combine a bunch of modules into a
> single, self-consistent, externally visible name space.  A good use
> for them.

It may be a good use for them, but you are describing a way to implement
the functionality I am describing manually.  I guess it depends whether
you typically use module organization within a package to support
information hiding or just code organization and literate comments.
Most of the time, if I think information hiding is very important, I want
a different package.  Java's package system has this orientation as well.
All classes in the same java package can access each other.

The re-export facility is nice, but I think it is more useful for
establishing what functions are visible to other packages then defining
what is visible within a package.
 
>    Here are the name space semantics Haskell should provide:
>    1. A package is a set of modules in the same directory and 
>       a cluster is a set of clusters, packages, and modules in the same
>       directory
> 
> We don't need all that mechanism.  See the VHDL library / package
> mechanism, for example.

I am not arguing for a lot of mechanism here, just an arbitrarily deep
directory tree in which to store modules (like Java, Ada, or Perl)
 
>    2. Packages and clusters should have a globally consistent name
>       space
> 
> Sure; however, this can be an artifact.  Binding library names to
> directories with user variables works just fine.

I am still not sure what you mean here.
 
>    3. Modules may import both other packages (all public declarations of all 
>       modules in the package) or individual modules in other packages
> 
> *shudder*.  I disagree here; it is too easy for a user to change a
> single name, produce name space pollution, and have no idea where it
> came from.  Much better to impose discipline of a single "gather
> module"; i.e., one that explicitly imports and reexports the
> appropriate names.
> 
> This one has bitten me before.  Really.

If all import was unqualified, I'd agree with you.  But there are times
when it is just much more convenient to import the entirety of what is
exported from another package, especially if you can import qualified.
 
>    5. Modules should have access to all functions in a package
>       without knowing the module in which the function sas declared
> 
> Given by the gather modules above.

True.  My proposal supports multiple gather modules.
(One might argue that a package should have only one public gather module,
but that strikes me as overly restrictive)
 
>    6. Modules should be able to hide specific declarations from their
>        own package
> 
> Explicit export?  Don't we have that?

No.  Right now there is just a flat module namespace.  So there is are no
packages to protect.  I am arguing for a distinction between keeping
things hidden from other packages and keeping things hidden from a
module's own package.  Without a packaging system, this disctinction is
not meaningful.

I am saying that these existing export rules should stay and apply to
packages.
 
>    7. Module level exports should define visibility to other packages
> 
> I am not quite sure what you mean by this.

Modules that share the same package have more access to each other's
contents than they do to modules of other packages.  When a module imports
its own package in an unqualified manner ("package->" in my syntax), it
gains access to all functions that are not declared private in all modules
in the package.  

However, other packages don't have access to functions in a module unless
those functions are exported by the module.

As I said above, this retains the existing rules for inter-package access.
 
>    I suggest the following (strawman) implementation syntax:
>    1. Module/package names should have a java-like import syntax e.g.
>       com->numeric_quest->fun_pdf (for Jan's haskell/pdf library) and map to
>       a directory structure (off of the source/lib path) of
>       com/numeric-quest/fun-pdf
> 
> As much as I dislike getting into syntax wars, I've never found the
> java syntax here particularly salubrious.  It is too busy, and tends
> to make the task of finding like names by scanning the text
> difficult.

You say that a library name can make modules globally unique.  You need a
way of specifying library names and a way for the interpreter/compiler to
find them.  The java package convention relies on the domain name system
to ensure that package names remain unique and semantically meaninful.
Yes, this convention does make some package names overly long, but it does
guarantee uniqueness and provides a clear rule for adjudicating conflicts.

Mapping the name-space hierarchy to a directory hierarchy seems a natural
way of finding these libraries.
 
>    3. Accessing the current package with "package"
>    To import the contents of the current package use,
>    > package->
>    >  myVal = somePackageFunction 3
> 
>    "package" is a special keyword to denote the current package.
> 
> Also applicable to the current library.

I am not sure what you are saying here.
 
>    4. To hide specific declarations from the surrounding package,
>       declare them Private e.g.
>       Private myConst=2 (or would a private section be better?)
> 
> Controls on name export control are fine here, and the present module
> system provides this.

As I noted earlier, there is a distinction between hiding declarations
from other modules in the same package and hiding a declaration from
modules in other packages.  I am not wedded to this "Private" declaration,
but it seems a straightforward way of achieving the right level of control
over visibility.
 
> Really, what we have is not that bad, and doesn't require such major
> surgery.  One more level is all I see the need of, plus some minor
> tweaks.

I don't disagree. But there is already current discussion on changing the
scope of import and on what operator to scope modules e.g.
> bar = Just.foo                 -- illegal 
> bar = just.foo where just=Just -- legal

Hierarchical namespace is my biggest ax to grind and SPJ has already said
that it would be straightforward to unflatten module namespace.  
My post combined all these issues into a single one and tried to address
the problems with the different treatment of inter-package and
intra-package visibility.

That being said, if Haskell simply added support for hierarchical
namespace and a standard path convention for finding libraries and source,
I would be ecstatic.  Better scoping, nicer import operators, and more
visibility control are just bonus.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media  
1-212-697-0184 voice                    1-212-697-1427 fax