Two questions about the guile module system

Two questions about the guile module system

[Joris van der Hoeven]

Hi,

How can I do the following:

1) Define a module which combines all exports of a set of
   other modules. Is there an analogue of the export keyword
   which exports all exports of an imported module?

2) Consider the following code

   main.scm:

	...
	(use-modules (library))
	...
	(use-modules (module))
	...

   library.scm

	(define-module (library))
	(export foo ...)
	...

   module.scm

	(define-module (module))
	...
	(foo)
	...

   The problem with this code is that, after loading main.scm,
   the 'foo' symbol will not be visible in module.scm even though
   this symbol is available in the context where module.scm
   was imported. Nevertheless, if I define foo in main.scm,
   then there is no problem...

   Is there a way to import library.scm or module.scm,
   such that foo remains visible in module.scm?

Thanks, Joris


-----------------------------------------------------------
Joris van der Hoeven <vdhoeven@texmacs.org>
http://www.texmacs.org: GNU TeXmacs scientific text editor
http://www.math.u-psud.fr/~vdhoeven: personal homepage
-----------------------------------------------------------



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Two questions about the guile module system

[Marius Vollmer]

Joris van der Hoeven <TeXmacs@math.u-psud.fr> writes:

> 1) Define a module which combines all exports of a set of
>    other modules. Is there an analogue of the export keyword
>    which exports all exports of an imported module?

There is no supported keyword to do this, but if you are determined
enough, you can dig into the internals of the module system and do it
yourself.

> 2) Consider the following code

What about:

     module.scm
 
 	(define-module (module)
          :use-module (library))

 	...
 	(foo)
 	...

This way, 'module' says explicitely that it is using bindings from
'library'.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Two questions about the guile module system

[Joris van der Hoeven]

> > 1) Define a module which combines all exports of a set of
> >    other modules. Is there an analogue of the export keyword
> >    which exports all exports of an imported module?
> 
> There is no supported keyword to do this, but if you are determined
> enough, you can dig into the internals of the module system and do it
> yourself.

I would like something more standard than that. I also think that
a good module system should have a mechanism for what I want.

> > 2) Consider the following code
> 
> What about:
> 
>      module.scm
>  
>  	(define-module (module)
>           :use-module (library))
> 
>  	...
>  	(foo)
>  	...
> 
> This way, 'module' says explicitely that it is using bindings from
> 'library'.

That is precisely what I do not want to do. The point is that
I have not one library module, but dozens of them. I do not want
to respecify all of them over and over again.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Two questions about the guile module system

[Marius Vollmer]

Joris van der Hoeven <TeXmacs@math.u-psud.fr> writes:

> > What about:
> > 
> >      module.scm
> >  
> >  	(define-module (module)
> >           :use-module (library))
> > 
> >  	...
> >  	(foo)
> >  	...
> > 
> > This way, 'module' says explicitely that it is using bindings from
> > 'library'.
> 
> That is precisely what I do not want to do. The point is that
> I have not one library module, but dozens of them. I do not want
> to respecify all of them over and over again.

Then what about making a new macro that does this speciying for you?

For example:

    (define-macro (define-my-module name . rest)
      `(define-module ,name
         :use-module (library)
         ,@rest))

You then only need to make sure that 'define-my-module' is available
in the current module when you load a file that uses it.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Two questions about the guile module system

[Joris van der Hoeven]

> > > What about:
> > >
> > >      module.scm
> > >
> > >  	(define-module (module)
> > >           :use-module (library))
> > >
> > >  	...
> > >  	(foo)
> > >  	...
> > >
> > > This way, 'module' says explicitely that it is using bindings from
> > > 'library'.
> >
> > That is precisely what I do not want to do. The point is that
> > I have not one library module, but dozens of them. I do not want
> > to respecify all of them over and over again.
>
> Then what about making a new macro that does this speciying for you?
>
> For example:
>
>     (define-macro (define-my-module name . rest)
>       `(define-module ,name
>          :use-module (library)
>          ,@rest))
>
> You then only need to make sure that 'define-my-module' is available
> in the current module when you load a file that uses it.

This is not very satisfactory either, in my opinion.
But I did find a way to hack exporting all symbols
from the public interface of a module.
With this, both my original questions can be answered.
Here is the code:

  (define-macro (export-from . which-list)
    (define (module-exports which)
      (let* ((m (resolve-module which #f))
	     (m-public (module-ref m '%module-public-interface #f))
	     (l '()))
        (module-for-each (lambda (symb . tail) (set! l (cons symb l))) m-public)
        l))
    (let ((l (apply append (map module-exports which-list))))
      `(export ,@l)))

If you want to include that piece of code into Guile,
then please go ahead. One might want to replace 'export'
by 're-export' in recent versions of Guile.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Two questions about the guile module system

[Joris van der Hoeven]

Hi again,

I now notice that my solution from yesterday
does not work with more recent versions of guile.
Unfortunately this is not the first time that
I found Guile to be unstable...

On 31 Mar 2003, Marius Vollmer wrote:
> For example:
>
>     (define-macro (define-my-module name . rest)
>       `(define-module ,name
>          :use-module (library)
>          ,@rest))
>
> You then only need to make sure that 'define-my-module' is available
> in the current module when you load a file that uses it.

This does not work either, because you usually don't *load*
a module, but *use* it via the command 'use-modules'.
When doing that (I tried in Guile 1.6.3), then the whole context
from where you issued the 'use-modules' command is lost.
This makes it impossible to enhance the root environment
with even a single macro like 'define-my-module'.

Someone has a solution for this problem?
I am more and more getting the impression that
the module system sucks... Worse: it was better
in older versions of Guile.


-----------------------------------------------------------
Joris van der Hoeven <vdhoeven@texmacs.org>
http://www.texmacs.org: GNU TeXmacs scientific text editor
http://www.math.u-psud.fr/~vdhoeven: personal homepage
-----------------------------------------------------------



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Two questions about the guile module system

[Marius Vollmer]

Joris van der Hoeven <TeXmacs@math.u-psud.fr> writes:

> I now notice that my solution from yesterday does not work with more
> recent versions of guile.

I have tested it with guile-1.6.3 and recent CVS HEAD; both work fine.
What version are you talking about and what goes wrong?

(Btw, there is also module-map which might be more natural to use in
place of module-for-each.)

> Unfortunately this is not the first time that I found Guile to be
> unstable...

Yeah, that's right.  Hopefully, it is 'reasonably' stable and people
are happy to switch over to the new ways because they are obviously
better.  That seems not to be true in your case, unfortunately, so I
like to know more.

> This makes it impossible to enhance the root environment
> with even a single macro like 'define-my-module'.

I find this not to be true, but it is indeed tricky to reason about
the context in which modules are loaded.

> Someone has a solution for this problem?

There certainly is a solution, but you need to specify your problem
more precisely, I'm afraid.

> I am more and more getting the impression that the module system
> sucks... Worse: it was better in older versions of Guile.

What was better about it in what versions?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Two questions about the guile module system

[Joris van der Hoeven]

> > I now notice that my solution from yesterday does not work with more
> > recent versions of guile.
>
> I have tested it with guile-1.6.3 and recent CVS HEAD; both work fine.
> What version are you talking about and what goes wrong?

The code does indeed re-export all symbols from an imported module,
but it does not solve my original problem.

In guile 1.3.4, I could put the following in my main initialization file:

  (use-modules (boot-stuff)) ; defines export-from
  (use-modules (std-lib-1) ... (std-lib-n))
  (export-from (std-lib-1) ... (std-lib-n))
  ...
  (use-modules (appl-mod-1) ... (appl-mod-k))
  ...

When doing this, I can use all variables exported by
the standard libraries std-lib-1, ..., std-lib-n
inside appl-mod-1, ..., appl-mod-k.

Unfortunately, this mechanism breaks in guile-1.6.3.
The point is that, during the importation of
appl-mod-1, ..., appl-mod-k, the outer context is lost.
It seems that only a very minimal context is visible
inside the application modules.

Nevertheless, before the actual (define-module (appl-mod-i))
definition is issues, the original context *is* visible.
So if one defines a 'define-my-module' macro,
then that macro can be used, although this might be unsafe.

> (Btw, there is also module-map which might be more natural to use in
> place of module-for-each.)

What does that routine do?

> > This makes it impossible to enhance the root environment
> > with even a single macro like 'define-my-module'.
>
> I find this not to be true, but it is indeed tricky to reason about
> the context in which modules are loaded.

So how can I make things such that whenever I declare a new module,
then all symbols which are visible in the initial context
are available by default?

This important, since I also noticed that even the C++ routines
which I glued to Guile are not available inside my modules!



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Two questions about the guile module system

[Joris van der Hoeven]

Hi again,

Yet another difference between Guile 1.3.4 and 1.6.3:
I can no longer use 'use-modules' inside a function.
Why has this possibility been prohibited?

As to our previous discussion, it seems that
the following code yields a cleaner module system
for the applications I have in mind.
It redefines 'use-modules' so that I can continue
to use it inside functions. Notice also the trick
with texmacs-top-level-module, which allows me
to extend the top level environment and to make
it visible inside all imported modules.
The code works with Guile 1.6.3.
I will now check for backward compatability.

-----------------------------------------------
(define texmacs-top-level-module (current-module))

(defmacro use-modules modules
  `(eval-case
    ((load-toplevel)
     (process-use-modules
      (list ,@(map (lambda (m)
		     `(list ,@(compile-interface-spec m)))
		   modules))))
    (else
     (process-use-modules
      (list ,@(map (lambda (m)
		     `(list ,@(compile-interface-spec m)))
		   modules))))))

(define-macro (inherit-modules . which-list)
  (define (module-exports which)
    (let* ((m (resolve-module which))
	   (m-public (module-ref m '%module-public-interface))
	   (l '()))
      (module-for-each (lambda (symb . tail) (set! l (cons symb l))) m-public)
      l))
  (let ((l (apply append (map module-exports which-list))))
    `(begin
       (use-modules ,@which-list)
       (export ,@l))))

(define-macro (texmacs-module name . options)
  (define l '())
  (define (process action)
    (cond ((not (pair? action)) (noop))
	  ((equal? (car action) :use)
	   (set! l (cons (cons 'use-modules (cdr action)) l)))
	  ((equal? (car action) :inherit)
	   (set! l (cons (cons 'inherit-modules (cdr action)) l)))
	  ((equal? (car action) :export)
	   (set! l (cons (cons 'export (cdr action)) l)))))
  (for-each process options)
  ;(display "loading ") (display name) (display "\n")
  `(begin
     (define-module ,name)
     (module-use! (current-module) ,texmacs-top-level-module)
     ,@l))
-----------------------------------------------



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Two questions about the guile module system

[Marius Vollmer]

Joris van der Hoeven <TeXmacs@math.u-psud.fr> writes:

> In guile 1.3.4, I could put the following in my main initialization file:
> 
>   (use-modules (boot-stuff)) ; defines export-from
>   (use-modules (std-lib-1) ... (std-lib-n))
>   (export-from (std-lib-1) ... (std-lib-n))
>   ...
>   (use-modules (appl-mod-1) ... (appl-mod-k))
>   ...
> 
> When doing this, I can use all variables exported by
> the standard libraries std-lib-1, ..., std-lib-n
> inside appl-mod-1, ..., appl-mod-k.
> 
> Unfortunately, this mechanism breaks in guile-1.6.3.
> The point is that, during the importation of
> appl-mod-1, ..., appl-mod-k, the outer context is lost.

The relevant difference between guile 1.3.4 and 1.6 is that in version
1.6, you are initially in the (guile-user) module, while in 1.3.4 you
are probably in the (guile) module.  What module you are in is of
course the module that you are exporting from with 'export-from'.

Now, the (guile) module is special in that its bindings are
automatically visible in all normal modules.  The ones from
(guile-user) are not automatically visible.

So when you export-from the (guile) module, the exported bindings
become visible in all other modules, including in the (appl-mod-...)
modules.

To access bindings exported from (guile-user), you must explicitely
'use' it, just like any other module.


I think it is best to change your code to

   (define-module (std-libs))

   (use-modules (boot-stuff)) ; defines export-from
   (use-modules (std-lib-1) ... (std-lib-n))
   (export-from (std-lib-1) ... (std-lib-n))
   ...
   (use-modules (appl-mod-1) ... (appl-mod-k))
   ...

and add a (use-modules (std-libs)) to any module that needs it.
(Probably all (appl-mod-...) modules and maybe also the (std-lib-...)
modules.)

> It seems that only a very minimal context is visible
> inside the application modules.

A module starts out with all bindings from the (guile) module visible.
What you did in Guile 1.3.4 was to 'accidentally' add bindings to the
(guile) module, which of course made them automatically visible
everywhere.

> > (Btw, there is also module-map which might be more natural to use in
> > place of module-for-each.)
> 
> What does that routine do?

It is to module-for-each what map is to for-each: it returns a list of
the results of applying the proc to each symbol/variable pair.  You
can use it like:

    (define-macro (re-export-from . which-list)
      (define (module-exports which)
        (let* ((m (resolve-module which #f))
               (m-public (module-ref m '%module-public-interface #f)))
          (module-map (lambda (sym var) sym) m-public)))
      (let ((l (apply append (map module-exports which-list))))
        `(re-export ,@l)))

> > > This makes it impossible to enhance the root environment
> > > with even a single macro like 'define-my-module'.
> >
> > I find this not to be true, but it is indeed tricky to reason about
> > the context in which modules are loaded.
> 
> So how can I make things such that whenever I declare a new module,
> then all symbols which are visible in the initial context
> are available by default?

You will need to put those enhancements into the (guile) module.  I'm
not sure whether that is unconditionally a good idea since you are
changing the nevironment for all code, not just for your own.

So, a better alternative is maybe to make a new 'use-modules' variant
that makes sure that modules are loaded in a controlled environment.

> This important, since I also noticed that even the C++ routines
> which I glued to Guile are not available inside my modules!

They are probably in the (guile-user) module as well.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Two questions about the guile module system

[Marius Vollmer]

Joris van der Hoeven <TeXmacs@math.u-psud.fr> writes:

> Yet another difference between Guile 1.3.4 and 1.6.3: I can no
> longer use 'use-modules' inside a function.  Why has this
> possibility been prohibited?

Statements like 'define-module', 'use-modules', 'export', etc are
meant to describe the environment of some code in a static way.  A
compiler should be able to interpret them at compile time.

Manipulating the module system at run-time is of course also
important, but we prefer to use more explicit code for it, like
the function 'module-use!'.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Two questions about the guile module system

[Paul Jarc]

Marius Vollmer <mvo@zagadka.de> wrote:
> I think it is best to change your code to
>
>    (define-module (std-libs))
>
>    (use-modules (boot-stuff)) ; defines export-from
>    (use-modules (std-lib-1) ... (std-lib-n))
>    (export-from (std-lib-1) ... (std-lib-n))
>    ...
>    (use-modules (appl-mod-1) ... (appl-mod-k))
>    ...
>
> and add a (use-modules (std-libs)) to any module that needs it.
> (Probably all (appl-mod-...) modules and maybe also the (std-lib-...)
> modules.)

That would result in circular dependencies.  Does use-modules handle
that?


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Two questions about the guile module system

[Marius Vollmer]

prj@po.cwru.edu (Paul Jarc) writes:

> That would result in circular dependencies.  Does use-modules handle
> that?

Yes.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user