In the following code, what I'm trying to understand is ...
why does the namespace seem to treat functions and macros separately? In particular, there does not seem to be anyway for me to access 'bar' in test2 once I (export)
~/magic$ cat test.scm (define (foo x) (list x x)) (define-macro (bar x) `(list ,x ,x)) ~/magic$ cat test2.scm (export) (define (foo x) (list x x)) (define-macro (bar x) `(list ,x ,x)) ~/magic$ bsc
(import test) foo
#<procedure #2 test#foo>
bar
*** ERROR IN ##main -- Macro name can't be used as a variable: bar
*** EOF again to exit ~/magic$ bsc
(import test2) foo
*** ERROR IN (console)@2.1 -- Unbound variable: ~#foo 1> bar *** ERROR IN (console)@3.1 -- Unbound variable: ~#bar 2> test2#foo #<procedure #2 test2#foo> 2> test2#bar *** ERROR IN (console)@5.1 -- Unbound variable: test2#bar 3> 2> 1>
*** EOF again to exit
i realize there are workarounds to this ... but
Afficher les réponses par date
In the following code, what I'm trying to understand is ...
why does the namespace seem to treat functions and macros separately? In particular, there does not seem to be anyway for me to access 'bar' in test2 once I (export)
~/magic$ cat test.scm (define (foo x) (list x x)) (define-macro (bar x) `(list ,x ,x)) ~/magic$ cat test2.scm (export) (define (foo x) (list x x)) (define-macro (bar x) `(list ,x ,x))
(export) takes a list of identifiers to export. Files with no (export) form are treated specially, and export everything. This is to make BH able to use R5RS code out of the box. So you either 1) have no export form, or 2) have an export form which declares everything to be exported, for instance
(export foo bar)
I usually develop modules without export forms first, then, when I want to clean up the public API, add an export form. There is a utility function for this called module-generate-export-list, that returns an export form that is equivalent to not having one at all:
(module-generate-export-list 'test2)
Should return something like (export foo bar)
/Per
In the following code, what I'm trying to understand is ...
why does the namespace seem to treat functions and macros separately? In particular, there does not seem to be anyway for me to access 'bar' in test2 once I (export)
foo
*** ERROR IN (console)@2.1 -- Unbound variable: ~#foo 1> bar *** ERROR IN (console)@3.1 -- Unbound variable: ~#bar 2> test2#foo #<procedure #2 test2#foo> 2> test2#bar *** ERROR IN (console)@5.1 -- Unbound variable: test2#bar
Functions and macros are treated separately because they are a different thing. The reason that test2#foo works, but not test2#bar is that foo is an actual variable, while test2#bar is a macro, which is not in the Gambit runtime. BH does all macro expansion, including resolving all variables to fully qualified names. If the user writes a fully qualified name, BH ignores it.
Another way to explain it is to say that the fact that the test2 module gets the test2# namespace is a "coincidence"; BH will try to choose a namespace that is similar to the name of the module, but in by design it could choose any namespace. It chooses a similar one to make it easier to understand stack traces and similar. (In the current version, it will in fact always choose the same namespace as the module name, but that's a bug and is the next thing I will fix)
The reason the namespace#variable is allowed at all is for debugging; if you get an error message regarding a certain function, the function name you get from Gambit will be fully qualified. That way you could type in the fully qualified name in the REPL and access it.
Any use of namespace#variable notation in BH is to be used for hacking purposes only, because there is no guarantee that a module will have the same namespace on two different machines. The hygienic macro facilities of BH remove the need for this notation. It is still useful when messing around with the REPL though.
/Per