erm, have you looked at the remote-repl egg?
fwiw, i don't see why this is an issue at all... just send quoted lists
(stringified, of course), and eval it on whichever end is desired.
-elf
On Fri, 24 Oct 2008, Shawn Rutledge wrote:
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
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
