Recursive namespace

[Keisuke Nishida]

At Mon, 23 Apr 2001 14:58:59 +0900 (JST),
NIIBE Yutaka wrote:
> 
> Well, here's the evidence where "recursive namespace" still lives.
> 
> Directory structure
>     --- m.scm (module which exports symbol "x")
>         m     ---- x.scm (the module named "x" under module "m")
(snip)
> Here, the symbol "x" in module "m" pollutes the module (m x).

> While current module system supports a kind of relative path to access
> module (by nested-ref), I don't think it is useful.  All that we need
> is absolute path.

Hmm, the idea of "recursive namespace" is one thing that I am
thinking of implementing in the module system for my VM.

I'd like to allow the following notation for inter-module
variable accesses:

  (List::list-ref '(0 1 2) 1)  => 1

Here, "List" is the module name, and "list-ref" is the variable name.
Now, what happens if you evaluate the following?

  List    => ???

My personal favorite would be that it returns the module named "List".
In this case, we can understand the "::" notation in terms of the
following expansion:

  (List::list-ref '(0 1 2) 1)  -->

  ((module-ref List 'list-ref) '(0 1 2) 1)   => 1

You notice that we can implement "::" notation as a syntax
expansion.  I think this is a good thing.

Let's think about the following variable:

  OOP::GOOPS::make

This would be expanded as follows:

  (module-ref (module-ref OOP 'GOOPS) 'make)

This means that the variable `make' is defined in the module
named `GOOPS', which is defined in the module OOP.  This is the
idea of recursive namespace.

Top level variables, like `List' and `OOP', are imported by
a syntax `use' as follows:

  (use List)
  (use OOP)

These are essentially identical to the following

  (define List (module-ref (root-module) 'List))
  (define OOP (module-ref (root-module) 'OOP))

except that the compiler understands `use' as a special
keyword and does optimization.

Thus, all modules and variables are organized into a single
hierarchy as follows:

  (root-module)     <module>
    List            <module>
      list-ref      <procedure>
      ...
    OOP             <module>
      GOOPS         <module>
        make        <procedure>
        ...
    ...

In order to avoid confusion, I call modules that are intended
to export different modules "packages".  In the above example,
the root module and OOP are packages.

The problem you encountered in the example of two modules
(m) and (m x) was caused by a fact that you defined a normal
variable `x' in the module (m), even though it is in fact
a package.  You should not do that in this module system.

Based on these ideas, the compiler globally identifies most
variables at compile time, which I hope allows good optimization
and fast loading.

This system has flexibility as well.  For example, you can
write the following:

  ;;;
  ;;; Short name access

  (use OOP::GOOPS)  -->
  (define GOOPS (module-ref (module-ref (root-module) 'OOP) 'GOOPS))

  GOOPS::make  ;; same as `OOP::GOOPS::make'

  ;;;
  ;;; Variable import

  (import List)  -->
  (begin
    (define list-ref (module-ref (module-ref (root-module) 'List) 'list-ref))
    ...
    )

  list-ref     ;; same as `List::list-ref'

  ;;;
  ;;; Run-time lookup

  (define m (module-ref some-module name))

  m::foo  -->  (module-ref m 'foo)

I am at the beginning of the design of this module system and
not sure whether this is a good system or not.  What do you think?

Keisuke