S. Alexander Jacobson writes:
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.
I beg your pardon; I was inspecific. I meant adding a library name to
the syntax of names, thus allowing a triple of <library> <module>
<name> for resolving the ambiguity of the name space. Thus, modules
can have the same name where ncessary.
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.
I am describing precisely that; however, I am also saying it is a good
thing, better than having it done manually. This puts the onus on the
user to control his name space for his own package, which I maintain
is a Good Practice. It also places this information in a specific
place, where the user can go to find out the definition of specific
names should it be necessary.
All this has little to do with whether information hiding is important
or not. It is simply a discussion of how it is to be implemented.
Information hiding needs differ within a package from those who use
the facility as a whole. A single module serving as a "visibility
gather point" does this just fine.
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.
But export is where information hiding is (or should be) defined;
otherwise it is not information hiding per se, but name space control
(the information is not hidden). My contention is that export is
precisely where information hiding should take place, and that the
current facility provides this well.
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)
And I am arguing that arbitrarily deep is not needed, and introduces
more complexity than is worth while. It's not a major point in my
personal system of programming beliefs, but other languages (VHDL
really does come to mind) do just fine with a triple as above.
> 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.
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.
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.
Then I would go with a separate gather module, to make specific what
you are doing. It isn't much overhead to type. The mechanism you
describe makes it too easy to establish a multi-headed import hydra
without thinking about it.
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)
I'll accept multiple public gather modules.
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.
Hmmm. I thought that public gather modules did just this. I have the
sneaking suspicion that I am missing something fundamental in your
proposal. My cranial density is sometimes legendary.
I am saying that these existing export rules should stay and apply to
packages.
Last comment applies; either public import-export (gather) modules
provide this, or I am missing something pretty basic here.
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.
To be a bit more specific; it seems that we have this mechanism now.
1) intra-package visibility provided by explicit export lists from
modules within a package.
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.
If this doesn't do what you are suggesting, then (again) I am missing
something basic. As you stated above, it is a manual operation (or,
at least, is implemented in a separate package; I suppose there is
nothing inherently against having a tool produce the gather module).
I regard this manual maintenance of the package visibility name space
as a good thing, not a bad thing ("it's a feature, not a bug" :-)).
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.
The mapping is fine; I just suggest that the way to do it is via user
variables, with no mechanism attached to the language other than
reading the directory names from the user variables. I see no reason
to impose any mechanism on the language itself; consider a future
operating system that grants such access across the Internet, or that
fetches libraries from a dealer and charges the user accordingly.
User variable bindings can accomodate virtually any change of this
sort without requiring a change to the language syntax.
Pardon my personal history, but I really am biased a bit by my
background here. VHDL, while undergoing standardization, made the
deliberate decision delete a directory like library / package
structure from the language, and substitute for it 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. We have never regretted this; it has made a
bunch of different library mechanisms possible, including different IP
(intellectual property) charging mechanisms. I regard including a
directory structure in a language as a step backwards, and would hate
to see Haskell move in this direction.
> 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.
In a triple scheme as above, the keyword "library" can point to the
current library just as the keyword "package" can refer to the current
package.
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.
See comment above; either we have this two tiered mechanism, or I am
missing something.
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.
I really do think that one additional level (from the <module> <name>
pair to a <library> <module> <name> triple) and mapping between
libraries and directories via user variables is all we need. I see
leaving the mapping mechanism outside the language as a bonus, not a
detriment.
This has gotten awfully long, even snipping as much as I felt
comfortable with. Apologies to all who think the two of us are making
much ado about nothing.
Dave Barton <*>
[EMAIL PROTECTED] )0(
http://www.intermetrics.com/~dlb
