S. Alexander Jacobson writes:
I agree, but then my questions is how do you choose library names?
The same way you choose variable names; as meaningfully as possible
given the limited creativity of the average programmer! Recall that
my suggestion was to map the library name to directories (or whatever
mechanism would be used to fetch the modules) via user variables. To
the Haskell code, a library name would be an identifier, pure and
simple. Part of installation is to choose library names and user
variable assignments that are (again, hopefully) meaningful.
The advantage to this is that it avoids codifying a directory
hierarchy method or structure in the language. This seems best left
to the operating system, with them mapping documented in the user
variable assignments.
How does VHDL adjudicate name space?
In a variety of different ways, depending on which part of the
language you are dealing with (confusing, I know --- the worst
complication is a design unit called a configuration, which walks down
a design hierarchy mapping component declarations to
entity-architecture pairs). The relevant part here, however, is the
design unit name space. This consists of a two level structure,
consisting of a library name (where a library is simply a collection
of design units) and a design unit (module) name. The mapping between
library names (identifiers) and directories (or whatever defines the
collection of design units) is made explicitly outside the language.
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.
My suggestion would be that the *only* rule in the Haskell definition
is that a library is a collection of modules. Mapping a library name
to the modules should be explicitly outside of the language, and left
to the operating system. Reason: different operating systems, and
programming environments, do things differently. This does *not*
interfere with portability; it increases it by not imposing a mapping
from an arbitrary directory structure onto all destination systems.
Of course, it also keeps the language definition simple.
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.
I am confused. Why on earth not? Only things in the export list of
the gather nodes are exposed.
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).
There is a distinction between setting up a convention and enforcing
it; I would suggest that defining an enforcement mechanism in the
language is overspecifying the language definition. This should
properly be left to the programming environment. On a Unix system, it
could be implemented by granting group and world read privileges only
to the public gather modules. In a configuration controlled system,
it can be controlled by the CC system.
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.
Given that I think this suggestion an excellent idea, I am having a
hard time figuring out where we differ. Perhaps I was confusing your
name visibility suggestions with language feature suggestions, where
your context was considerably broader. My only sticking point is the
inclusion of the full directory name in the Haskell code; I would
prefer a simple declaration that an identifier is a library name, and
leave the binding of that name to the collection of modules it
contains to the programming environment.
Dave Barton <*>
[EMAIL PROTECTED] )0(
http://www.averstar.com/~dlb