[plt-scheme] eval not aware of vars defined in same function as caller

Hi Robby,

Thanks for the fast answer. So it seems we do have
some second-class citizens, ie, the lexical variable.

Eval'd code may not be able to see lexical vars of the
caller but I found that the caller *can* see lexical
variables defined via eval (and this eval works
anywhere in the function, not just at top).  I seem to
have solved the problem with that trick in combination
with injections of set!s into an s-expression that is
itself eval'd.

May not be the best approach but I'm enjoying the
compactness of the resulting code (which allows
conventional table-name.column-name notation in a
sql-like mini-language).

best,
George Herson

--- Robby Findler <robby.findler at gmail.com> wrote:

> The namespace only binds top-level identifiers, not
> lexical ones. g is
> not in the current namespace.
> 
> Robby
> 
> On 2/25/07, George Herson <gherson at snet.net> wrote:
> > (define f 5)
> > (define test
> >   (lambda ()
> >     (define g 4)
> >     (display (eval '(* f 3)))(newline)
> >     (display (eval '(* g 6)))))
> > (test)
> > ============>
> > 15
> > reference to undefined identifier: g
> >
> > Why is g undefined?  EVAL should be using the
> current
> > namespace, where g /is/ defined.  The "PLT
> MzScheme:
> > Language Manual" says:
> > (eval expr [namespace]) evaluates expr in
> namespace,
> > or in the current namespace if namespace is not
> > supplied.
> >
> > The error is the same if I specify
> (current-namespace)
> > in the latter EVAL call.
> >
> > thank you.
> >
> > George Herson
> > _________________________________________________
> >   For list-related administrative tasks:
> >  
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> >
>