# Environments

**URL:** <https://discourse.pushlanguage.org/t/environments/93>\
**Category:** Orientation\
**Created:** [July 21, 2015, 12:39am UTC](https://discourse.pushlanguage.org/t/environments/93 "2015-07-21T00:39:58Z")\
**Posts on this page:** 9\
**Page:** 2

<div class="post-metadata">

**Author:** ![lspector](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.pushlanguage.org/lspector/32/4_2.png) [@lspector](https://discourse.pushlanguage.org/u/lspector)\
**Post date:** [October 22, 2017, 7:54pm UTC](https://discourse.pushlanguage.org/t/environments/93/22 "2017-10-22T19:54:56Z")

</div>

PS in making the above-mentioned changes, I noticed (remembered?) that the way tag spaces are returned from environments is weirdly all-or-nothing. If I’m understanding it correctly, **all** changes to the tag space in an environment are lost when you leave it, _unless_ you execute `return_tagspace`, in which case they are **all** retained (or maybe just those after or before the call? not sure about that).

If anybody is looking at how environments and tags interact (and/or wants to try an idea we’ve discussed, of automatically wrapping tag-retrieved code in environments), then you should definitely take a closer look at this and maybe consider alternatives.

---

<div class="post-metadata">

**Author:** ![jscacco](https://avatars.discourse-cdn.com/v4/letter/j/a698b9/32.png) [@jscacco](https://discourse.pushlanguage.org/u/jscacco)\
**Post date:** [June 27, 2018, 4:28pm UTC](https://discourse.pushlanguage.org/t/environments/93/23 "2018-06-27T16:28:07Z")

</div>

Looking into implementing map/filter for the code and exec stacks in Push, and I believe that environments will be necessary in doing so. After doing some initial experimentation, I wonder: would there be any benefit to flushing the stacks after creating a new environment? It seems like it might be beneficial to have a truly empty environment when creating a new one. Or perhaps not, since it wouldn’t follow with the idea of a “local scope” for Push. What are everyone’s thoughts?

---

<div class="post-metadata">

**Author:** ![mcphee](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.pushlanguage.org/mcphee/32/3_2.png) [@mcphee](https://discourse.pushlanguage.org/u/mcphee)\
**Post date:** [June 27, 2018, 4:53pm UTC](https://discourse.pushlanguage.org/t/environments/93/24 "2018-06-27T16:53:44Z")

</div>

I’ve never actually _used_ environments in Push, so feel free to ignore all of this. My sense, though, is that environments are kind of like a function call. In most programming languages data comes in to a function call via arguments, and leaves via return values (or pointers or globals if you’re in an ickier part of the world).

In that context, I would expect a new environment to have a clean set of stacks, which it can then populate at will, using information passed in arguments as necessary.

In theory the arguments could be on stacks, but I think this is probably Not A Good Idea; the fact that @thelmuth, et al, moved to primarily having input registers instead of inputs on stacks is a sign of this. Inputs on stacks is fragile and hard to work with if there are lots of arguments that you process in a non-linear way.

The trick, though, is then figuring out how to evolve the number/type of arguments and how they’ll be made available to the new environment. Lots of people have gotten stuck on that part of the problem in related systems, and I don’t have any great ideas there, I’m afraid.

---

<div class="post-metadata">

**Author:** ![lspector](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.pushlanguage.org/lspector/32/4_2.png) [@lspector](https://discourse.pushlanguage.org/u/lspector)\
**Post date:** [June 27, 2018, 6:37pm UTC](https://discourse.pushlanguage.org/t/environments/93/25 "2018-06-27T18:37:37Z")

</div>

The idea we had in mind, I think, is that arguments _would_ be passed in via stacks, in part because the implementation for this is _just leave all of the stacks as they are_, and because the numbers and types of arguments that code executed in an environment get is just _whatever they want_.

So it’s a function call that has access to all data in the calling environment, and returns just what it explicitly says to return with `return_*` and `return_*_pop` instructions.

Since that seemed both flexible and easy, it’s what we did. That said, I don’t think that anybody has any idea whether it’s actually a good design!

Another option is to always flush the stacks when entering an environment, and to rely on tags to bring in arguments. This would still allow the number and types of “arguments” that are actually used to evolve.

Note that that last suggestion probably interacts with (open?) issues regarding how tagspaces are processed when returning from environments… I haven’t looked back at that part of this thread to figure that out.

With respect to your larger goals, @jscacco, did you know that there’s already a `code_map` instruction? It’s uncommented and I don’t know if it’s documented anywhere, so maybe not! 😊 Also, maybe it doesn’t do what you want. And I don’t think we have or maybe have ever had a `code_filter`, which sounds like a nice idea to me.

---

<div class="post-metadata">

**Author:** ![jscacco](https://avatars.discourse-cdn.com/v4/letter/j/a698b9/32.png) [@jscacco](https://discourse.pushlanguage.org/u/jscacco)\
**Post date:** [June 27, 2018, 7:34pm UTC](https://discourse.pushlanguage.org/t/environments/93/26 "2018-06-27T19:34:51Z")

</div>

Funnily enough, I didn’t know that `code_map` was already implemented! However, @thelmuth and I discussed creating a map/filter that utilizes new environments so that the existing stacks would not need to get involved in keeping track of the process. The idea being that keeping track of the mapping and such within the base environment could lead to unintended manipulation of the program.

This is following some changes I made in my own fork over the past few weeks: I implemented an `:index` stack that is used by iterative instructions as well as those that input/output a number. I am not sure what effect this has had on the general effectiveness of the system, as I am currently waiting on test results from the HPC.

So, I think I will attempt to recreate `code_map`, as well as add `exec_map` that utilizes environments. I think that, in order to do this, I might want to change the way the return stack works and perhaps implement it in the system as a whole. I’ll keep you updated!

---

<div class="post-metadata">

**Author:** ![thelmuth](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.pushlanguage.org/thelmuth/32/2_2.png) [@thelmuth](https://discourse.pushlanguage.org/u/thelmuth)\
**Post date:** [July 1, 2018, 7:37pm UTC](https://discourse.pushlanguage.org/t/environments/93/27 "2018-07-01T19:37:21Z")

</div>

I see lots of good ideas here, and without any good intuition as to what would be friendliest to evolution, I’d suggest an empirical comparison might be useful.

1. Use environments as-is, with full stacks copied.
2. Flush stacks when entering an environment.

If 2, then there are further options for passing arguments:

1. Keep the tagspace, so that it could be used for passing arguments.
2. Use registers in some way like the automatic `in1`, `in2`, etc. instructions. I could imagine this being the easiest option for implementing something like map/filter, since the element of the list under consideration could be the value passed to the register.
3. Maybe we need a stack like the `return` stack, except opposite: an argument stack. Its instructions would move items from other stacks to the argument stack, which would then be pushed onto the appropriate (flushed) stacks when a new environment is started. This option sounds potentially the most general, but also maybe the most complex to code, and maybe the hardest for evolution to use.

Anyway, I would certainly be interested in seeing experimental comparisons between two or more of these!

---

<div class="post-metadata">

**Author:** ![lspector](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.pushlanguage.org/lspector/32/4_2.png) [@lspector](https://discourse.pushlanguage.org/u/lspector)\
**Post date:** [August 14, 2018, 9:14pm UTC](https://discourse.pushlanguage.org/t/environments/93/28 "2018-08-14T21:14:35Z")

</div>

Does anyone recall if Push environments have been described in any publications (aside from this thread 🙂)?

---

<div class="post-metadata">

**Author:** ![thelmuth](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.pushlanguage.org/thelmuth/32/2_2.png) [@thelmuth](https://discourse.pushlanguage.org/u/thelmuth)\
**Post date:** [August 15, 2018, 3:16pm UTC](https://discourse.pushlanguage.org/t/environments/93/29 "2018-08-15T15:16:49Z")

</div>

Not to my knowledge. I don’t think we’ve used them in any experiments that were published. I can think of a few instances of where we’ve used them in conjunction with other things (tags, @jscacco’s map/filter instructions), but I don’t know that we’ve even done a vanilla “does adding environment instructions help” experiment.

---

<div class="post-metadata">

**Author:** ![lspector](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.pushlanguage.org/lspector/32/4_2.png) [@lspector](https://discourse.pushlanguage.org/u/lspector)\
**Post date:** [August 15, 2018, 3:23pm UTC](https://discourse.pushlanguage.org/t/environments/93/30 "2018-08-15T15:23:33Z")

</div>

> [@thelmuth](#):
>
> I can think of a few instances of where we’ve used them in conjunction with other things (tags, @jscacco’s map/filter instructions), but I don’t know that we’ve even done a vanilla “does adding environment instructions help” experiment.

@aks has also done some experiments in conjunction with tags… and we just discussed some other ideas that I’ll move to another thread (since this one is in Orientation).

[Previous page](https://discourse.pushlanguage.org/t/environments/93.md?page=1)