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

[S. Alexander Jacobson]

This discussion seems to be mixing a few different issues.  I believe any
proposal here needs to satisfy three criteria:

1. it must allocate top level name space in a way that prevents collisions
2. it must allow an implementation to resolve names to locations efficiently
3. it must give developers control over the visbility of their objects

Name Space Policy:

The main issue here is what name policy allows developers to collaborate
most effectively without stepping on each others toes.

David said:
> A globally consistent name space can be produced by binding directory
> names to library names known inside the Haskell modules via user
> variables.  The triple is all that is needed for global consistency.

I agree, but then my questions is how do you choose library names?

My suggestion for the former is to rely (like Java) on the conventions of
the domain name system for managing library name space.  Note, this is not
distinct from using a triple.  It just specifies the structure of the
library names themselves.  So a triple for one of Fergus's function would
be:
Libary: http://www.cs.mu.oz.au/mercury/mmc/mprof/compiler/hlds
Module: hlds_goal
Function/Type: Compile

Of course, as in java, Fergus could always violate this convention:
Library: mercury
Module: compiler
Function: Compile

but the domain name rules provides a way for adjudicating conflict when
someone else also decide to make a fast compiler named Mercury.

Name Resolution May Add Another Level:

David said:
> VHDL, while undergoing standardization, [...]
> a simple library name scheme where the binding of the library name to
> the group of packages / design units (Haskell modules) was explicitly outside the
> language definition.  [...] it has made a bunch of different library
> mechanisms possible, including different IP (intellectual property) charging 
>mechanisms. 

How does VHDL adjudicate name space?
Note that using the dns rules for haskell does not necessarily require
that all modules in a library are in the same directory, nor does it
require that libraries be stored in a constistent directory structure.
It only ensures that name space is clean. 
Note also that DNS itself allows machines in the same domain to be in
physically separete locations and that Java's library name space is
also separate from directory structure in that it supports downloading
libraries from URL's as well as accessing them on the local disk.

As a matter of course, it would be ideal if an implementation could
first look for the code locally, and if it is not present, find it by
asking the relevant directory/http server.  To me this means that library
names should be either an (LDAP server,id) tuple or, more simply, a URL.


Visibility (Packaging, Gather Nodes, etc):

Programmers and organizations need control over which functions and
datastructures they expose to others.  Gather nodes without a notion of
public/private do not provide this control.

David says:
> To be a bit more specific; it seems that we have this mechanism now.
> [...]
> 2) inter-package visibility provided by (possibly multiple) public
>    import-export (gather) modules that form the interface to the
>    entire package, where a gather module is defined as one that
>    contains no code, but a series of import statements and a re-export
>    list.

But gather nodes do not prevent other programmers from importing
implementation modules directly and bypassing the gather nodes.
There should be some facility for specifying which modules of a package
are publicly visible and which are purely for use by other modules within
the package (or local cluster).
However, I do agree with David that separating library issues from language
issues is a good thing, I propose this library system:

The implementations should have a make-library command that 

1. takes as arguments
  * a library name 
  * the names of the public gather nodes
  * access permissions for the library
2. uses import chasing to find the implementation modules
3. constructs a package (jar/tar/zip?) through which only the named
    modules are visible to other programmers (renames the other modules?)

Access permissions specify which other libraries may access the public
datastructures of this library.  For example, a library might provide a
set of useful datastructures for the implementation of mercury, other
components of mercury might use this library, but these components really
should not be visible to the outside world in the context of mercury.  So
the permissions would be: "http://www.cs.mu.oz.au/mercury/*"
On the presupposition that all code eventually becomes a library, the
library builder would produce an error if you tried to build a library
that used modules to which you didn't have access (note that permissions
are an issue of regular expression matching in make-lib and not a language
issue per se).

Make-lib requires no changes to the haskell language itself,
however allowing url-style module names does require a small change in the
syntax of import statements.  This change is orthogonal to the local
import issue.

I tried to summarize and reorganize this argument into its relevant
pieces.  I hope it worked.

-Alex- 

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