Re: Quick question: eval and read-from-string scoping



"Kaz Kylheku" <kkylheku@xxxxxxxxx> wrote in
news:1135895978.803972.101550@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

> A lexical scope is "baked" at compile time.

I understand.

> You can eval a lambda expression to produce a function. That function
> can take parameters. You can funcall the resulting function, and use
> local variables as arguments.

It doesn't sound like I can do it from a text string, but I'll look into
it.

>> I realise that special variables can be re-defined using 'let' and
>> they are passed down to any functions called by the parent, but this
>> doesn't appear to be working when calling eval. Code run by eval
>> cannot see the re-bound special variables. Odd!
>
> It does work with eval. Maybe you have a package-related problem.
> Perhaps your code (the function, and the special variables, and all)
> is defined in some package, but then when the function is called
> called, READ-FROM-STRING is in a different package.

It's not in a package, but the code to eval the read-from-string is in a
macro. I guess I'm way in over my head and need to simplify things a bit
and re-read the chapters in Practical Common Lisp on Macros (which I am
doing).

> That doesn't explain why these attributes have to be direct references
> to lexical variables in your evaluator. You can transform the code
> before you EVAL it, turning it into functions that take parameters.
> E.g. if CODE contains the source code of an expression that is known
> to refer to the variables A, B and C, you can do this:
>
> (eval `(let ((a ,value-for-a) (b ,value-for-b) (c ,value-for-c))
> ,code))
>
> In other words, build up a larger piece of source code which
> establishes bindings for A, B and C, and whose body is that
> expression. The initial values for these variables are stuck in via
> backquote substitution.

This sounds like a great idea.

> You don't have to eval the "naked" forms that you are reading from the
> description language files.

I didn't know this could be done that easily. Your use of commas in that
code sample are new to me. Thanks for the information, and I'll try your
example, it should work well.

Happy New Year,

Jeremy.
.



Relevant Pages

  • Re: On the limits of our?
    ... "An our declaration declares a global variable that will be visible ... even across package boundaries." ... Once the lexical scope in which the 'our' is ... Global variables already exist. ...
    (comp.lang.perl.moderated)
  • Re: Scheme closures
    ... > hosed CMUCL, requiring me to suspend it and kill it from the shell. ... > think I'll stick to lexical scope for my functions:) ... should make your own package then). ... you seem to be a bit confused about the semantics of ASSOC. ...
    (comp.lang.lisp)
  • Re: Quick question: eval and read-from-string scoping
    ... it's a character string that only becomes ... > And now I realise that eval is like a function, and local variables are ... > I realise that special variables can be re-defined using 'let' and they ... READ-FROM-STRING is in a different package. ...
    (comp.lang.lisp)
  • Re: Modules, global variables and such
    ... Gunnar Hjalmarsson schrieb: ... from somewhere outside the MyModule package. ... can use that variable unqualified for the rest of the lexical scope, ... have someone else's fun. ...
    (comp.lang.perl.misc)
  • Re: Frage zu Packages und our
    ... An "our" declaration declares a global variable that will be ... visible across its entire lexical scope, even across package ... The package in which the variable is entered is ...
    (de.comp.lang.perl.misc)