[plt-scheme] "transitivity" in module namespaces

I tested this and your right,
(require  "xx.ss")
(PC? `(correct pc list))

gives in the interaction environment:
. reference to undefined identifier: var?
> var?
#<procedure:var?>
> 

(require  "xx.ss")
(define var? `lame-temp-value)
(PC? `(correct pc list))
 
gives:
procedure application: expected procedure, given: lame-temp-value;
arguments were: (a a b)


I guess i'm a little supprized at that while xx.ss provides var?, var?
is not counted in the top level environment.
I did find if i put var? in a seperate module which was loaded before
xx.ss, then var? does count as being in the environment, so i'm
guessing that provided names aren't counted as being defined in the
top level untill after the module is required, (after in the sence of
code position, not time).

One of my ideas has been to attempt wrapping all the special forms
with eval in some way to make first class versions of them all.  I
realize that i'm probably the only person on the planet who can think
of this as a good thing, and I'm fine with that.  I've got some ideas
for ways to use it.

Anway, I case I get ambitious, and want to try something clever...  do
you have continuations blocked from jumping in and out of the middle
of module code?

hmm.  perhaps my answer would be to create a differnt, but
syntactically compatible module system, that would allow these things
as first class objects, then let you convert them to "traditional
modules" when it came time to write your compiler (i.e. traditional
macros).  Not sure.  Just kinda brainstorming.

Anyway, thanks for the responce.

Corey



On Apr 5, 2005 7:57 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> 
> At Wed, 30 Mar 2005 11:25:07 -0600, Corey Sweeney wrote:
> > ;;;;;;;;file bp.ss
> > (module bp (lib "plt-pretty-big-text.ss" "lang")
> > (provide b->p)
> > (require (lib "plt-match.ss"))
> >
> >  ;;use match in a function that's a first class citizen
> > (define (bnf->p list-in)
> >         [...]
> > (let ((match-expression
> >            (append
> >             `(lambda (x) match x)
> >               [... list-in ...]
> >               )))
> >       (eval match-expression)))))
> 
> `eval' always uses the current namespace as determined by the
> `current-namespace' parameter. By default, then, symbols (as opposed to
> syntax) in the argument to `eval' get attached to the top-level
> environment, not to any module's environment.
> 
> > ;;;;;;;;next file xx.scm
> > (require "bp.ss")
> >
> > ;define what a var is
> > (define (var? x)
> >     [...]
> >     )
> >
> > (define P-BNF
> >   `(
> >      [...]
> >     (? var?)
> >      [...]
> >      ))
> >
> > (define PC? (bnf->p P-BNF))
> 
> In this case, you've bound `var?' in the top level environment, so it
> works.
> 
> > ;;;;;;;;next file xx.ss
> > (module xx
> > (require "bp.ss")
> > (provides PC?
> >               var?)
> >
> > ;define what a var? is
> > (define (var? x)
> >     [...]
> >     )
> >
> > (define P-BNF
> >   `(
> >      [...]
> >     (? var?)
> >      [...]
> >      ))
> >
> > (define PC? (bnf->p P-BNF))
> >
> >
> > ;;;;;;;;then next file yy.scm
> > (require  "xx.ss")
> > (PC? `(correct pc list))
> >
> >
> > then the call to PC? returns:
> >
> >           ---reference to undefined identifier: var?---
> 
> In this case, there's no top-level binding.
> 
> > so i thought it's geting eval'ed under the wrong namespace, so i make
> > var? available in every namespace (i cut and paste a copy of "define
> > var?" to bp.ss).  But even after this i still get the same error.
> 
> Putting `var?' definitions in multiple modules still leaves it
> undefined in the top level environment.
> 
> Put another way, a module is not a "namespace" in MzScheme terminology
> (although it's possible to obtain a namespace that corresponds to the
> module body --- but that feature is intended for exploring and
> debugging).
> 
> If you use syntax objects instead of plain S-expressions, then things
> will probably work as you expect, because identifiers will become
> associated to bindings when the identifier is created, instead of when
> the identifier is `eval'ed.
> 
> Matthew
> 
>