nested modules / anonymous modules

[Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>]

Hi,

I think these are good points:


> leave all administration of names to the module system
[...]
> To me this suggests that there should be a module border between
> these groups.  This is exactly what module borders are for.  I don't
> understand what "class interface" would mean within a module.
[...]
> I *do* understand the need to limit access to a subset of the slots of
> a class within the API. 
[...]
> I think the module system should support multiple modules per file.



How should a module system meeting the above requirements look like?
Five attempts:


1. A module has nested modules thus building a hierarchical name space.

;; within the root module
(define a 99)
(module ice-9
	(export ...)

	(begin ;; within the ice-9 module

		(define a (+ a 1))
		(module test 
			(export ...)
			
			(begin ;; within the ice-9/test module

				(display a) ...))))

This solution is as good as having no module system at all.


2. Modules are independent from each other but may access each other's features.

;; within the `the-module'
(define-module (ice-9 test)) ;; equal to: (set! the-module (make-new-module ice-9 test))
;; evaluate expressions in the-module
(define x 99)

(define-module (ice-9 test2) :use-module (ice-9 test))
...


This solution uses a single global variable to switch from one module
to another.  Which means that only one module at a time can exist.  Also
a translation table is needed for mapping a filename to a module name.


3. No global state variable and a "meta" module which describes the state
of all modules and carries their signatures.

;; in the "meta" module (let's call it `config-module'):

(define some-value 1)
(define mod-signature1
	(module (ice-9 test)
		(open (ice-9 debug))
		(export ...)
		(begin 
			(define a 12)
			some-value ; -> error
			(module ...; -> error
			))))

some-value -> 1

(define mod-signature2
	(module (ice-9 test2))
		(export ...)
		(file ...)) 



;; jump right into our (ice-9 test) module:
(go (ice-9 test))
a -> 12


The problem that we need a translation table `(file ...)'  remains.
With the `(file ...)' directive module signatures are pointing to files
telling the user "hey, that's me over there" ...


4.  One file -- one module


--------------------------------------------- in file ice-9/test --
(module (ice-9 test)
	(open (ice-9 test2))
	(export ...))

(define a 12)
y -> 99 ;; imported from module (ice-9 test2)
...
(the-module) -> (ice-9 test)
--------------------------------------------- end of file ice-9/test ---



-------------------------------------------- in file ice-9/test2 ----
;; when the (module ...) declaration is missing
;; all symbols are exported from the current module
(define y 99)

;; yes, this is really the ice-9/test2 module!
(the-module) -> (ice-9 test2) 

-------------------------------------------- end of file ice-9/test2


Although it is possible to byte compile the file ice-9/test2 so that
the module loader will automatically load the compiled module in
favour of ice-9/test2.scm it is not possible to define more than
one module per file.



5. More than one module per file with nested modules

Definition:  A nested module is a anonymous module which is contained
in another module and doesn't have an import clause.


------------------------------------------- in file ice-9/test -------
(module (ice-9 test)
	(open (ice-9 test2))
	(export x2 x))

(define y 12)
(define x
	(module (export x y gen)
		(define y (+ y 1))

		(define-class my-class ()
			(x #:accessor x))
		
		(define-method gen ...)))

x -> module


(define x2
	(module (export x y gen)
		...
		(define-class my-class2 ()
			(x #:getter x))))

(module-ref x2 x) -> generic 
(module-ref x x) -> generic with setter

...
------------------------------------------- end of file ice-9/test ----



Regards,
Jost