[Push] Re: Re Environments

[Lee Spector]

Maarten (& Push list folks),

I agree -- let's move this to the Push list.

[ Other folks: this may be confusing since you're getting it 
mid-stream, but maybe it'll make some sense if I provide the context 
that we're talking about the following "Under Discussion" item from 
http://hampshire.edu/lspector/push2-description.html:

- Environments (containing stack states, variable binding states, 
perhaps more) as first class entities, along with associated 
instructions that allow for the execution of code within specified 
environments. This might allow for the "safe" execution of arbitrary 
code fragments (which would be executed in a fresh environment and 
would not be able to affect the the environment of the remainder of the 
code). Ideas for this range from minimal extensions (e.g. "DO&" which 
executes in a fresh environment, plus a mechanism to get the results 
back to the calling environment) to a full-fledged ENVIRONMENT type 
with a stack, etc. (Suggested by Maarten Keijzer.)

I'll provide old emails in this thread to anyone who's interested... ]
[ to continue...]

Maarten,

I just read your PushGP-in-Push-with-ENVIRONMENT-stack example more 
carefully and I do now see the potential convenience of an environment 
stack as you've specified it. But it does still seem somehow too 
complicated to me... I'm not sure I've clearly thought through the 
reason for that impression. I'd like to mull it more.

If we do stick with the minimalist DO& and DO*& idea (to execute code 
in a new null environment) then I think your "&" suffix idea is a good 
approach to getting results out of the "sandboxed" execution 
environment.  But we shouldn't allow YANK& exactly, since that changes 
the YANKed-from stack -- presumably we only want to provide read (not 
write) access. So I'd propose that we provide, for each type, just 
YANKDUP&, DUP& (which just copies the top element -- same as "0 
YANKDUP&" but doesn't require the 0), STACKDEPTH&, and GET& (allowing 
access to the NAME binding space of the returned-from environment). 
Sound right?

  -Lee

P.S. I added your "rejected" names to the spec document -- the 
corporate ring of push.INC is particularly amusing!



On Jan 12, 2004, at 7:06 PM, Maarten wrote:

> Hi all,
>
> maybe we should bring this discussion to the push-list as I'm sure a 
> bit of
> traffic will not hurt.
>
> In any case, I was thinking about the DO& alternative and think it'll 
> probably
> do this sandboxing without the need to make the environment a type 
> with a
> stack. Considering that you can pack an initial environment in a CODE
> statement, this will do the job.
>
> So, one fresh environment for any DO& call. Still to consider is how 
> to get
> the values out of this embedded environment. I've got a suggestion for 
> this,
> not completely thought out but maybe interesting. Simply suffix the 
> existing
> generic stack operations with a '&' symbol and we're done. So you can 
> have
> YANK&, STACKDEPTH&,  but maybe not SHOVE&, nor DUP&. In effect, these
> functions will read stuff from the child stacks and push them on their 
> own.
> Simple and effective (though I still like the full-fledged type idea).
>
> Just and idea,
>
> -Maarten, who has a touch of insomnia tonight-
>
>
--
Lee Spector
Dean, Cognitive Science + Associate Professor, Computer Science
Cognitive Science, Hampshire College, Amherst, MA 01002
lspector at hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438