Re: [Chicken-users] basic Scheme question

[Drake Wilson]

Quoth Shawn Rutledge <address@hidden>, on 2008-10-24 12:02:52 -0700:
> Oh, maybe you are right though: maybe the symbol 'v doesn't exist
> anymore, because in the counter example, the accessor only needs to
> access the number to which 'v was bound.  So it can replace the symbol
> with a reference to the number, and therefore the symbol lookup only
> occurs when the lambda is eval'd (the s-expression is converted to a
> procedure).  After the binding has been converted to a reference, the
> symbol 'v cannot be looked up anymore.  Does that sound right?

That's pretty much what I meant, yes.  The Scheme system has already digested
the name "v" into a lexical reference.  In a language like Perl where you can
do things like:

  sub foo { my $foo = "bar"; eval '$foo'; }

the language system (of whatever sort) is required to preserve the names of
the variables (among other things), which is a different tradeoff.

You may be able to write a "name-preserving-let" macro of some kind, but
I suspect that this is not actually what you want, or at least not yet.

> >  (let ((v (client-do (make-thing))))
> >      ;; Now v contains a token to an object on the other side.
> 
> The entire "let" block runs on the other side.  The server does not
> need the object that was created on the client, it just needs a kind
> of remote reference or name that can be used to refer to that object.

That's what I meant by "token".

If the entire let block runs on one side by itself, where is the other
side going to ever have access to bindings inside the let block?  I'm
not sure why you're insisting on "getting access to v"; the only thing
that comes out of a let is side-effects and the result value of the let.
If you mean that you have some kind of escape inside to request further
commands from the non-let side, then perhaps I'm misunderstanding what
you mean by "the entire block runs on one side".

> But, the concept of requiring the server to make up names in order to
> be able to access remote objects after having created them may turn
> out to be cumbersome, so I was thinking about serializable proxy
> objects.

Now you're getting into general distributed environment design.  Be
prepared for things to get tricky.

> That provoked further thought: the direction this is heading is that
> destructive operations are to be preferred over pure functional
> operations.

Why?

   ---> Drake Wilson