On Fri, Oct 24, 2008 at 1:00 AM, Drake Wilson <[EMAIL PROTECTED]> wrote: > Quoth Shawn Rutledge <[EMAIL PROTECTED]>, on 2008-10-23 23:54:03 -0700: >> > Eval only sees the top-level environment. It may be possible to use >> > the environments egg to construct your own environment containing v. >> >> I thought of that, but also thought there must be a generic Scheme way >> to do this. > > From someone with admittedly limited Scheme knowledge: > > The generic Scheme way wouldn't involve passing around quoted names and > expecting them to retain their associations to the original lexical symbols > at runtime, because they generally don't. > > The generic Scheme way would probably be to have a function encapsulate the > idea of reading and writing the variable inside a "location" structure of > some sort (pair of get+set function, likely) and then have the other function > interact with that.
Right that's the usual pattern. But I'm trying to call it remotely. A client REPL opens an SSH connection to a server and starts a server REPL. Each of them evaluates what the other sends. So if the server sends (let ([v (make-thing)]) ...) and the client evaluates it, then later the server wants to ask the client to do any operation on the previously-created v, how can the client now access the variable v, which exists only in that environment created by "let"? Just binding it to a top-level name would pollute the namespace. Having to bind the accessor is not so bad, because the same accessor can be used to modify multiple remote objects. _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
