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
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.