Re: Hierarchical name space
Hi, Andy Wingo writes: > Hi, > > On Thu 08 Apr 2010 01:01, l...@gnu.org (Ludovic Courtès) writes: > >> Julian Graham writes: >> I'm still inclined to think that the module namespace hierarchy (and it is a hierarchy) should not impinge on the environment of an evaluation. But, not something we can change right now. >>> >>> This is actually causing me some difficulty -- I'm implementing the >>> R6RS composite library, which imports and then re-exports the bindings >>> of a lot of the individual R6RS standard libraries. I'm running into >>> a problem with `(rnrs syntax-case)', which exports `syntax-case'. >> >> Unfortunately I don’t think a module names can contain ‘syntax-case’, >> just like they can’t contain ‘eval’, ‘+’, etc. :-( > > Explain more? Well, the problem has apparently vanished in 1.9: --8<---cut here---start->8--- $ cat foo.scm (define-module (foo) #:export (bar)) (define bar 1) $ cat foo/eval.scm (define-module (foo eval) #:export (foo)) (define foo 2) $ guile -L . GNU Guile 1.9.9 Copyright (C) 1995-2010 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> (use-modules (foo)) ;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-autocompile argument to disable. ;;; compiling ./foo.scm ;;; compiled /home/ludo/.cache/guile/ccache/2.0-0.P-LE-8/home/ludo/src/nixpkgs/foo.scm.go scheme@(guile-user)> (use-modules (foo eval)) ;;; compiling ./foo/eval.scm ;;; compiled /home/ludo/.cache/guile/ccache/2.0-0.P-LE-8/home/ludo/src/nixpkgs/foo/eval.scm.go scheme@(guile-user)> $ ./result/bin/guile -L . guile> (use-modules (foo)) guile> (use-modules (foo eval)) ERROR: In procedure struct-vtable: ERROR: Wrong type argument in position 1 (expecting struct): # ABORT: (wrong-type-arg) guile> (version) $1 = "1.8.7" --8<---cut here---end--->8--- Fishy... Thanks, Ludo’.
Re: Hierarchical name space
Hi, On Thu 08 Apr 2010 01:01, l...@gnu.org (Ludovic Courtès) writes: > Julian Graham writes: > >>> I'm still inclined to think that the module namespace hierarchy (and it >>> is a hierarchy) should not impinge on the environment of an evaluation. >>> But, not something we can change right now. >> >> This is actually causing me some difficulty -- I'm implementing the >> R6RS composite library, which imports and then re-exports the bindings >> of a lot of the individual R6RS standard libraries. I'm running into >> a problem with `(rnrs syntax-case)', which exports `syntax-case'. > > Unfortunately I don’t think a module names can contain ‘syntax-case’, > just like they can’t contain ‘eval’, ‘+’, etc. :-( Explain more? > I can’t think of a work around. We need to separate module namespaces from value namespaces. Lazy binding / module lookup can be implemented differently from lazy binders. Andy -- http://wingolog.org/
Re: Hierarchical name space
Hi, Julian Graham writes: >> I'm still inclined to think that the module namespace hierarchy (and it >> is a hierarchy) should not impinge on the environment of an evaluation. >> But, not something we can change right now. > > This is actually causing me some difficulty -- I'm implementing the > R6RS composite library, which imports and then re-exports the bindings > of a lot of the individual R6RS standard libraries. I'm running into > a problem with `(rnrs syntax-case)', which exports `syntax-case'. Unfortunately I don’t think a module names can contain ‘syntax-case’, just like they can’t contain ‘eval’, ‘+’, etc. :-( I can’t think of a work around. Thanks, Ludo’.
Re: Hierarchical name space
Hi Andy and Ludo, > I'm still inclined to think that the module namespace hierarchy (and it > is a hierarchy) should not impinge on the environment of an evaluation. > But, not something we can change right now. This is actually causing me some difficulty -- I'm implementing the R6RS composite library, which imports and then re-exports the bindings of a lot of the individual R6RS standard libraries. I'm running into a problem with `(rnrs syntax-case)', which exports `syntax-case'. Using the conventional set of module system introspection procedures (`module-ref', `module-variable', etc.), there's no way to see the syntax transformer and not the module -- to obtain the former, you need to use `nested-ref' (or some other workaround) instead. Any ideas? Regards, Julian
Re: Hierarchical name space
On Wed 31 Mar 2010 22:42, l...@gnu.org (Ludovic Courtès) writes: > Hey, > > Andy Wingo writes: > >> Also in every module that has submodules, like (language tree-il) and >> (language tree-il compile-glil), the "supermodule" has a binding for the >> submodule. Do a (module-ref (resolve-module '(ice-9)) 'threads) >> sometime. > > I think I found a possible use case for the hierarchical name space. :-) > > Suppose we want something like PLaneT or Eggs, let’s call it GUMM > (Guile’s Unified Module Machinery). Ideally, we’d want to be able to > write this: > > (use-modules (gumm foo bar)) Ew. I even forgot that I did this with slib a while back. I'm still inclined to think that the module namespace hierarchy (and it is a hierarchy) should not impinge on the environment of an evaluation. But, not something we can change right now. A -- http://wingolog.org/
