Talk:First class environments

So it's what, the thing we normally call "closure"? --Ledrug 09:14, 30 June 2011 (UTC)

No, because a closure cannot be handled independently from the code, e.g. stored in a variable and activated at some other time with a piece of code.--Abu 09:19, 30 June 2011 (UTC)

Concerning the question whether the C solution "fits the spirit": I would say yes, though instead of switching the pointers to 'sec' and 'cnt' I would save and restore the actual values. This would better simulate the "binding" of the "environments".--Abu 15:17, 30 June 2011 (UTC)

Well, that's quite a bit more work. Right now I can just swap the links (addresses) and forget about it (which is in a sense more "real"), if I copy values, I'd have to copy them back after each job switch, can't exit job control loop whenever I want, etc. The way I look at it, just pretend the "*" is a special marker for environment variables. In the worst case, the job function itself can copy and restore them to stack if really needed. --Ledrug 16:40, 30 June 2011 (UTC)

Flyweight?

What is the exact relationship between this and the flyweight pattern? --Michael Mol 16:44, 30 June 2011 (UTC)

Is there any at all? --Ledrug 16:47, 30 June 2011 (UTC)

I can't detect any. Flyweight patterns seem to be mainly concerned about sharing data structures, not about runtime variable bindings.--Abu 16:58, 30 June 2011 (UTC)

Ledrug's initial question was quite close. A "closure" is a combination of environment and code. AFAIK, in most languages the environment cannot be separated from a closure, and stored, retrieved and manipulated explictly. In PicoLisp it is the other way round: Environments can be constructed from normal Lisp data, and then perhaps be used to build a clojure, but also for other purposes.--Abu 17:17, 30 June 2011 (UTC)

Runtime_evaluation/In_an_environment?

The concept seems close to Runtime_evaluation/In_an_environment. The initial implementation there was Common Lisp, by the way. —Sonia 18:36, 30 June 2011 (UTC)