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.
* 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.
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.
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.
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.
4 Modules may (on a block level) import qualified or unqualified
OK, I guess.
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.
6. Modules should be able to hide specific declarations from their
own package
Explicit export? Don't we have that?
7. Module level exports should define visibility to other packages
I am not quite sure what you mean by this.
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.
2. clusters and packages as functions
Generalize import. Treat clusters, packages, and modules as functions
which take a name and return a cluster, package, module, or function.
Since we don't want all names in all paths to pollute module name space, I
suggest using the "->" operator. e.g.
> myFun =\x -> com->numeric_quest->fun_pdf->somePDFFunction x
Use of -> in function definitions outside or on the right of lambda
expressions tells the compiler/interpreter to resolve an import.
You run into a slight problem with -> polluting the type namespace,
but clusters and package names are functions and are therefore lower case.
> myFun::Int -> (com->numeric_quest->fun_pdf->PDFDocument)
(If you want, you can interpret the type of myFun as taking an Int and
the fun_pdf package and returning a PDFDocument i.e. linking to
fun-pdf may happen at runtime)
Import renames work like function names:
> funpdf = com->numeric_quest->fun_pdf
If you want to combine the current namespace with the namespace of another
module or package, instead of the keyword "use", you do:
> com->numeric_quest->
> myFun = \x -> fun_pdf->somePDFFunction x -- fun_pdf is inside numeric_quest
> myVal = pdfConstant
> fun_pdf-> -- downscope
> myFun2 = \x -> anotherPDFFunction x -- anothterPDFFunction is in fun_pdf module
This should feel vaguely like using lambda expressions.
Is this basically an implementation suggestion? I'll leave it to
Simon and othersto comment.
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.
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.
The stuff below is more speculative and assumes a modularized Haskell
compiler/interpreter.
Then I'll bail out here.
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.
Dave Barton <*>
[EMAIL PROTECTED] )0(
http://www.intermetrics.com/~dlb
