This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Namespace protection from libguile


Lalo Martins writes:

 > I found this in the archives:
 > 
 >         ;;save current module
 >         (define top (current-module))
 >         (define x 1)
 >         x ; yields 1
 > 
 >         ;;create and switch to a new module, called (foo bar)
 >         (define-module (foo bar))
 >         (define x 2)
 >         x ; yields 2
 > 
 >         ;;switch back to the initial module
 >         (set-current-module top)
 >         x ; yields 1 again
 > 
 > Of course it doesn't really work, because inside "foo", "top"
 > will be unbound. But looks like a cool way to achieve namespace
 > protection.
 > 
 > The questions are: is there a way to make this work on scheme?
 > (Probably by making "foo" able to access toplevel symbol "top")
 > 
 > And more important, is there a way to make this work on C
 > (libguile)? Are there functions that do the job of
 > current-module, define-module and set-current-module?
 > 
 > I really hesitate to use this method because Godot may render it
 > completely useless, but I do have to use _something_ for now :-)
 > and this one sounds better than the other sollution someone
 > offered me (apart from the fact that I lost the message with
 > this alternative sollution).

my guess is that godot will maintain current interface (developers
please correct me if i'm wrong).

as i understand it, `define-module' does `set-current-module'
implicitly.  so the way to do the above is something like:

	(define-module (top))
	(define x 1)
	x => 1
	
	(define-module (foo bar))
	(define x 2)
	x => 2
	
	(define-module (top))
	x => 1
	
stuff like `current-module' and `set-current-module' should probably be
left alone unless you want to use module objects within procedures like
that required by `eval2' (the LOOKUP-CLOSURE arg).  i used to use this
approach in thud, but switched to a single-module (runtime) scheme to
avoid `eval2' overhead.  still, playing w/ `eval2' was fun, and i may
actually return to it in the future for un-compilable evaluations.  it
ain't cool unless you gotta eval...  :->

thi